refactor: implement runtime-owned table DDL

docs/benchmark-tool.md

@@ -270,15 +270,15 @@ doradb-bench --root target/doradb-bench/index-scan run index-scan --num 10000 --
 doradb-bench --root target/doradb-bench/index-scan cleanup
 ```
 
-## RFC-0025 Successful-Path Measurements
+## RFC-0025 and RFC-0026 Successful-Path Measurements
 
 The new workloads complete the pre-RFC successful-path shapes needed by
 RFC-0025:
 
 - Phase 1/2 statement and transaction evidence uses `stmt-noop` and
   `trx-noop`.
 - Phase 2's no-per-item stream budget uses `index-stream`.
-- Phase 4's successful table-DDL path uses `table-ddl`.
+- RFC-0026 Phase 2's runtime-owned table-DDL path uses `table-ddl`.
 - Phase 5's successful index-DDL path uses `index-ddl`.
 - Existing insert, lookup, table-scan, and index-scan workloads remain the
   row/index/page-loop evidence.

docs/engine-component-lifetime.md

@@ -183,6 +183,18 @@ shutdown. Conversely, a prepared caller future retained without being polled
 still owns its voluntary resources and can block shutdown until it resumes or
 drops.
 
+`CREATE TABLE` and `DROP TABLE` are the first production users of this caller
+contract. The session validates input, reserves its DDL operation, and acquires
+the complete target/catalog lock set while the future is still cancellable.
+After caller capacity is available, synchronous acceptance transfers the
+operation entry, locks, immutable execution plan, and exact table runtime (for
+DROP) to the mandatory owner. The public future then waits only through the
+execution-inert observer. Normal completion drops settled progress, releases
+the prepared locks, and only then publishes the outer operation terminal.
+Unexpected execution unwind instead retains `FailedRetained`, publishes
+mandatory-runtime poison, and releases the caller permit after the accepted
+owner is dropped.
+
 The supervisor catches both synchronous future construction and polling
 unwinds while the accepted operation or cleanup job remains in an outer owner.
 Its domain policy first releases or moves residual unsafe ownership into fatal

docs/lock-system.md

@@ -120,8 +120,8 @@ The current implementation uses the following table-level mapping:
 | Explicit shared table lock | session `S` | session `S` | explicit session |
 | Explicit exclusive table lock | session `S` | session `X` | explicit session |
 | Freeze/checkpoint | scoped `S` | scoped `IS` | maintenance operation |
-| CREATE TABLE on a new id | scoped `X` | none | DDL operation |
-| DROP TABLE | scoped `X` | scoped `X` | DDL operation |
+| CREATE TABLE on a new id | target `X`; catalog slots 0-3 `S` | catalog slots 0-3 `IX` | prepared DDL operation, then mandatory owner |
+| DROP TABLE | target `X`; catalog slots 0-4 `S` | target `X`; catalog slots 0-4 `IX` | prepared DDL operation, then mandatory owner |
 | CREATE/DROP INDEX | scoped `X` | scoped `X` | DDL operation |
 
 On first touch, statement metadata protection is handed to the transaction
@@ -138,6 +138,15 @@ Successfully bound reads therefore retain metadata protection until transaction
 commit or rollback. Repeated operations use the transaction binding and lock
 cache.
 
+Table CREATE/DROP acquire their complete fixed lock sequences while the public
+session future is still cancellable. Winning mandatory capacity synchronously
+transfers the same `OwnerLockState` and operation owner to accepted execution;
+there is no release/reacquire window. Catalog statements receive a typed
+prepared-write authority that proves metadata S plus data IX for each catalog
+table and bypasses ordinary transaction lock acquisition. Index DDL,
+maintenance, and ordinary catalog statements continue through their existing
+lock-manager paths.
+
 Recovery, purge, and no-transaction replay do not acquire logical locks. They
 run at lifecycle boundaries where foreground lock owners do not exist. Logical
 lock state is volatile and is never reconstructed from redo.

docs/public-error-audit.csv

@@ -1,8 +1,6 @@
 file,function_or_method,disclose_calls
 doradb-storage/src/catalog/index.rs,create_index_for_session,29
 doradb-storage/src/catalog/index.rs,drop_index_for_session,16
-doradb-storage/src/catalog/table.rs,create_table_for_session,11
-doradb-storage/src/catalog/table.rs,drop_table_for_session,12
 doradb-storage/src/engine.rs,Engine::new_session,1
 doradb-storage/src/engine.rs,Engine::try_shutdown,1
 doradb-storage/src/engine.rs,bootstrap_inner,23
@@ -20,9 +18,9 @@ doradb-storage/src/session.rs,Session::checkpoint_table_with_wait,3
 doradb-storage/src/session.rs,Session::cleanup_secondary_mem_indexes,3
 doradb-storage/src/session.rs,Session::close,3
 doradb-storage/src/session.rs,Session::create_index,1
-doradb-storage/src/session.rs,Session::create_table,1
+doradb-storage/src/session.rs,Session::create_table,4
 doradb-storage/src/session.rs,Session::drop_index,1
-doradb-storage/src/session.rs,Session::drop_table,1
+doradb-storage/src/session.rs,Session::drop_table,4
 doradb-storage/src/session.rs,Session::freeze_table,3
 doradb-storage/src/session.rs,Session::list_table_ids,1
 doradb-storage/src/session.rs,Session::lock_table,2

docs/table-file.md

@@ -202,6 +202,18 @@ publication or enqueue handoff. Consequently `DROP TABLE` either closes a
 reversible workflow immediately or asynchronously drains the publisher that
 already won admission.
 
+Public table DDL owns only preparation. `CREATE TABLE` validates its schema and
+prepares all logical locks before mandatory acceptance; the runtime-owned task
+then creates the provisional file, starts the private catalog transaction,
+publishes the initial root, builds the runtime, and preserves the existing
+precommit compensation policy. `DROP TABLE` similarly transfers the exact
+current-live runtime and complete lock scope before it closes the lifecycle and
+waits for any admitted publisher. Dropping the public future after acceptance
+does not abandon either file workflow. Ordinary failures still compensate
+inside accepted CREATE execution, while a panic or unsafe post-gate DROP
+failure is retained and poisons storage rather than running fallible cleanup
+from a destructor.
+
 ### 7.1 Data Checkpoint Publication
 
 Data checkpoint publishes: