refactor: harden mandatory runtime lifecycle fairness stats and readiness

docs/benchmark-tool.md

@@ -164,7 +164,7 @@ workloads accepts `--seed`.
 | `--batch-size`, `-b` | `prepare`, insert and non-stream read workloads | `prepare`: `1`; `run`: manifest default | Operations per transaction. For inserts this means rows per commit; for reads this means lookup/index-scan requests or table-scan iterations per read transaction. |
 | `--seed` | `run insert-seq`, `insert-rand`, `lookup-rand`, `index-scan`, `index-stream` | `0` | `u64` reproducibility input for payload bytes, randomized insert order, randomized read key selection, or randomized scan bounds. |
 | `--log-sync` | `run ...` | `fsync` | Redo-log durability sync method. `fsync` and `fdatasync` submit the matching native file-sync operation; `none` skips durable sync and is crash-unsafe. |
-| `--include-stats` | `run ...` | `false` | Captures and prints internal transaction-system, storage-IO, and buffer-pool stats. Omit this for prerequisite runs such as data loading before a measured read workload. |
+| `--include-stats` | `run ...` | `false` | Captures and prints internal transaction-system, storage-IO, buffer-pool, and engine-global mandatory-runtime stats. Omit this for prerequisite runs such as data loading before a measured read workload. |
 
 Run defaults resolve as follows:
 
@@ -221,7 +221,11 @@ errors are written to stderr.
   value size, batch size, seed, prepared index mode, loaded key range, threads,
   sessions, log sync mode, and table id.
 - `Internal Stats`, only with `--include-stats`: public transaction-system,
-  storage-IO, and buffer-pool stats deltas when available.
+  storage-IO, buffer-pool, and mandatory-runtime stats when available. The
+  mandatory snapshot is captured once per engine, not summed once per session;
+  its fixed names are `mandatory.operation.*` and
+  `mandatory.transaction_cleanup.*`. Monotonic fields are deltas and active
+  counts are the independently sampled ending values.
 - `Final Result`: operation count, inserted rows, found count, not-found count,
   returned rows, elapsed time, throughput, average nanoseconds per operation,
   and failures.
@@ -282,7 +286,7 @@ RFC-0025:
   `trx-noop`.
 - Phase 2's no-per-item stream budget uses `index-stream`.
 - RFC-0026 Phase 2's runtime-owned table-DDL path uses `table-ddl`.
-- Phase 5's successful index-DDL path uses `index-ddl`.
+- RFC-0026 Phase 3's runtime-owned index-DDL path uses `index-ddl`.
 - Existing insert, lookup, table-scan, and index-scan workloads remain the
   row/index/page-loop evidence.
 
@@ -316,14 +320,17 @@ baseline/candidate DDL trials should therefore use equivalently fresh prepared
 roots and normally one cycle per invocation:
 
 ```bash
-rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0025-table-ddl prepare --index none
-rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0025-table-ddl run table-ddl --log-sync none
-rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0025-index-ddl prepare --index none
-rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0025-index-ddl run index-ddl --log-sync none
+rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0026-table-ddl prepare --index none
+rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0026-table-ddl run table-ddl --log-sync none --include-stats
+rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0026-index-ddl prepare --index none
+rtk cargo run --release -p doradb-bench -- --root target/doradb-bench/rfc0026-index-ddl run index-ddl --log-sync none --include-stats
 ```
 
 The tool supplies workload shapes and fixed result artifacts, not repetition or
 aggregation. Users remain responsible for repeated paired baseline/candidate
 runs on the same host and configuration, then reporting median and dispersion.
-Checkpoint and persisted/cold measurements remain deferred to the backlogs
-linked at the start of this document.
+Checkpoint, freeze, shutdown/reopen, and persisted/cold measurements remain
+deferred to backlog 000147. Large rollback and heterogeneous DDL, maintenance,
+and internal-cleanup measurements require their separately designed
+`doradb-bench` backlog; the current homogeneous session runner and fixed engine
+configuration are not a substitute performance harness for those roles.

docs/engine-component-lifetime.md

@@ -175,6 +175,23 @@ submitted synchronously without a lossy channel. Independent transactions can
 therefore clean up concurrently, while each transaction's rollback remains
 sequential.
 
+`MandatoryRuntimeConfig::worker_threads` controls OS runners, not the accepted
+caller count. `concurrency_limit` bounds accepted caller obligations, not
+caller-side preparation futures or internal cleanup. Increasing caller
+capacity can retain more logical locks, memory, and publication work without
+increasing runner throughput. Increasing runners can increase storage and
+metadata contention and cannot make blocking code cooperative. Configuration
+is validated once during startup, rejects zero sizes, and cannot resize a
+running engine.
+
+One runner provides concurrency only when accepted work reaches an await or
+explicit yield that returns scheduler control. Multiple runners allow true
+overlap, but neither configuration promises executor ordering, a queue-latency
+bound, or a general fairness SLA. Internal admission is non-lossy and separate
+from caller backpressure; it intentionally does not create a bounded cleanup
+backlog because correctness obligations cannot be rejected after ownership is
+claimed.
+
 Mandatory results reuse the common completion cell through a move-once take
 path. The single observer owns no task, permit, engine reference, session
 authority, or prepared resource. Dropping it cannot cancel execution. A
@@ -218,6 +235,60 @@ and completion waiters are published, and the permit is released exactly once.
 If the domain panic policy itself unwinds, the panic-minimal fallback retains
 the whole armed owner instead of dropping raw-reference-sensitive undo.
 
+### Fixed-Class Statistics And Task Events
+
+`Session::mandatory_runtime_stats()` returns one engine-global snapshot with
+fixed `operation` and `transaction_cleanup` classes. Each class publishes
+monotonic `submitted_count`, `started_count`, `completed_count`,
+`error_count`, `panic_count`, `detached_observer_count`,
+`admission_wait_nanos`, `queue_wait_nanos`, and `execution_nanos` fields plus
+the current authoritative `active_count`. Fields are independently sampled;
+concurrent snapshots do not promise a transactionally consistent equation.
+The inspection remains available after poison while engine/session lifecycle
+inspection is admitted and creates no runtime work.
+
+Accepted caller task labels are `create_table`, `drop_table`, `create_index`,
+`drop_index`, `freeze_table`, `checkpoint_table`, `checkpoint_catalog`,
+`truncate_redo_log`, `checkpoint_catalog_and_truncate_redo_log`, and
+`cleanup_secondary_mem_indexes`. Internal cleanup labels are
+`terminal_rollback`, `abandoned_transaction`, and `failed_precommit`. These
+labels and the two class names are diagnostic vocabulary, not scheduling
+policy or a per-label registry.
+
+Every accepted task emits debug records with
+`event=mandatory_task component=mandatory_runtime`: `action=start result=ok`
+includes immutable class, task, optional session-operation/table identities,
+successful admission wait, and executor queue wait; `action=finish` reports
+`result=ok|error|panic`, the same identity, execution time, and
+`observer=attached|detached|none`. An unobserved ordinary error retains its
+error-level `action=discard_unobserved` record, and task panic retains the
+engine-poison error record. The storage crate does not install a logger.
+
+### Cooperative Poll Audit
+
+Accepted execution acquires no logical operation lock or metadata gate after
+the synchronous `PreparedExecution::accept` edge. The bounded-poll audit found:
+
+- CREATE/DROP TABLE and DROP INDEX perform bounded state transitions around
+  awaited storage, transaction, lifecycle, or publication boundaries.
+- CREATE INDEX hot-row collection and construction yield after their named
+  128-row batches; cold input proceeds through awaited storage batches. Its
+  larger bounded-memory/parallel redesign remains backlog 000104.
+- freeze/checkpoint, catalog checkpoint, redo retention/truncation, and
+  secondary `MemIndex` cleanup proceed through operation-specific awaited IO,
+  retry, scan-batch, or transaction boundaries. Synchronous filesystem regions
+  remain the runtime-independent blocking-work scope of backlog 000137.
+- terminal rollback, abandoned cleanup, and failed-precommit cleanup use the
+  same row/index undo paths. Those paths explicitly yield after 128 completed
+  undo entries, after the current entry is unlinked and popped and before the
+  next entry is borrowed.
+- normal finish and panic preservation perform fixed ownership publication or
+  move residual payloads into fatal retention; they do not reacquire operation
+  authority or loop on scheduler state.
+
+These boundaries provide cooperative progress evidence for the fixed runtime;
+they do not establish preemption or a general starvation-free scheduler.
+
 ## Admission, Shutdown, And Drop
 
 The engine lifecycle has three states:
@@ -234,6 +305,12 @@ shutdown can proceed.
 work remains. The infallible `Engine::shutdown()` waits for the same work to
 drain and returns only after final teardown completes.
 
+Lifecycle records distinguish `mode=try origin=explicit` from blocking
+`mode=wait origin=explicit|owner_drop`. A busy try-shutdown record and its
+returned attachment use the same `strong_refs`, `operation_blocked`,
+`operation_state`, `voluntary_blocked`, `mandatory_session_blocked`,
+`cleanup_queued`, `mandatory_callers`, and `mandatory_internal` fields.
+
 Normal shutdown is:
 
 1. close engine and mandatory caller admission and flip `Running -> ShuttingDown`
@@ -309,9 +386,11 @@ registry-owned component owners start their final `QuiescentBox<T>` drains.
 An unintended owner drop can therefore block indefinitely while
 caller-retained foreground work, runtime references, or engine-owned
 background work remains live. Callers should finish foreground work and invoke
-explicit shutdown at a controlled point when blocking there is operationally
-important. Drop does not cancel accepted work or tear down components before
-that work reaches terminal state.
+`try_shutdown` or explicit shutdown at a controlled point when blocker
+diagnostics and blocking location are operationally important. Drop does not
+cancel accepted work or tear down components before that work reaches terminal
+state. Future priority or reserved-runner lanes, adaptive sizing, task groups,
+and a separate blocking/CPU pool require workload evidence and separate design.
 
 ## Quiescent Ownership
 

docs/public-error-audit.csv

@@ -23,6 +23,7 @@ doradb-storage/src/session.rs,Session::drop_table,4
 doradb-storage/src/session.rs,Session::freeze_table,5
 doradb-storage/src/session.rs,Session::list_table_ids,1
 doradb-storage/src/session.rs,Session::lock_table,2
+doradb-storage/src/session.rs,Session::mandatory_runtime_stats,1
 doradb-storage/src/session.rs,Session::storage_io_stats,1
 doradb-storage/src/session.rs,Session::total_row_pages,3
 doradb-storage/src/session.rs,Session::transaction_system_stats,1

docs/rfcs/0026-engine-owned-mandatory-background-runtime.md

@@ -1248,9 +1248,12 @@ focused validation.
     finalize engine/session/runtime shutdown diagnostics, task/result
     observability, blocking owner-drop drain, bounded-poll audits,
     configuration documentation, cross-operation stress tests, and paired
-    performance measurements. Synchronize RFC-0025 Phases 3 through 7 as
-    superseded by this RFC and preserve the fixed-runtime implementation
-    evidence that closed backlog 000123. [D3] [D7] [D9] [B1]
+    performance measurements through workloads already implemented in
+    `doradb-bench`. Checkpoint/maintenance and large rollback/mixed-runtime
+    performance shapes require dedicated benchmark design and are not
+    approximated by test-only harnesses in this phase. Synchronize RFC-0025
+    Phases 3 through 7 as superseded by this RFC and preserve the fixed-runtime
+    implementation evidence that closed backlog 000123. [D3] [D7] [D9] [B1]
   - Goals: Demonstrate one execution owner, no dropped accepted payload,
     lossless shutdown wakeups, no transaction/statement hot-path overhead,
     bounded caller-operation backlog, progress for cleanup under
@@ -1261,18 +1264,23 @@ focused validation.
     caller preparation plus atomic prepared-runtime submission; no legacy
     foreground handoff or runtime-side operation-lock acquisition remains.
   - Phase-local Choices: Finalize stable diagnostic labels/counters, select
-    focused stress repetition counts and benchmark thresholds, and determine
-    whether new workload evidence justifies a follow-up scheduling-policy RFC
-    or separate work on backlog 000167.
+    focused stress repetition counts and benchmark thresholds for existing
+    table/index DDL, no-op, insert, lookup, scan, and stream commands, and
+    determine whether deterministic correctness evidence justifies a follow-up
+    scheduling-policy RFC or separate work on backlog 000167. Missing
+    checkpoint/freeze/shutdown-reopen performance coverage remains backlog
+    000147; missing large rollback and heterogeneous mandatory-runtime coverage
+    is recorded as a separate deferred `doradb-bench` backlog.
   - Non-goals: Do not implement adaptive resizing, priority lanes, parallel
     recovery/checkpoint/index algorithms, forced shutdown, or explicit
     operation cancellation.
-  - Task Doc: `docs/tasks/TBD.md`
+  - Task Doc: `docs/tasks/000252-mandatory-runtime-lifecycle-fairness-evolution-readiness.md`
   - Task Issue: `#0`
   - Phase Status: `pending`
   - Implementation Summary: `pending`
   - Related Backlogs:
     - `docs/backlogs/closed/000123-adaptive-background-worker-runtime.md`
+    - `docs/backlogs/000147-doradb-bench-checkpoint-lifecycle-scenarios.md`
 
 ## Test Strategy