fix(storage): enforce WAL hard-pressure drain before project WAL exceeds 256 MiB

[ScriptedAlchemy]

Defect

On the live operator profile at 2026-09-03T00:20:24Z (binary 0.1.0-beta.37+5de159b26), tracedecay status --runtime --json reported project shard proj_a5b3d7e3ebe14ca7 at wal_bytes=780,299,192 and aggregate wal_bytes=974,265,192, while wal_hard_limit_bytes=268,435,456. The project shard had been idle for 168,291 ms and its writer had 0 offered/admitted operations in this incarnation, so the >2.9x hard-limit state persisted beyond an active batch.

Contract contradiction

• crates/tracedecay-store/src/runtime/operation.rs defines and caps WAL soft/hard budgets at 32/256 MiB.
• crates/tracedecay-rusqlite-runtime/src/checkpoint/controller.rs classifies >= hard as hard pressure and retains hard_drain_required until checkpoint completion.
• crates/tracedecay-rusqlite-runtime/src/writer/worker/mod.rs maps hard pressure to BlockGeneral.
• crates/tracedecay-rusqlite-runtime/src/connection/mod.rs documents exceptional over-soft growth as tolerated only up to the 256 MiB hard limit and says it must not become permanent.

The live ready shard violated that contract.

Acceptance criteria

• Attribute why the scheduled PASSIVE checkpoint/hard-drain state allowed the WAL to reach 780 MiB. Include blocker inventory and hard-pressure retry telemetry.
• Do not raise the limit. Once hard pressure is reached, prevent further general writes and complete a bounded drain/checkpoint, or surface a typed degraded/faulted shard state naming the blocking leases instead of remaining ready.
• Add an integration test with a held snapshot/reader plus continued writes that proves WAL growth cannot silently exceed the configured hard limit and verifies recovery to <= soft after the blocker clears.
• Runtime status exposes the pressure/drain/blocker state whenever wal_bytes >= hard_limit_bytes.

[ScriptedAlchemy]

Root-cause triage on the current PR #707 tip:

1. CheckpointPressure::BlockGeneral is published when a PASSIVE checkpoint is incomplete at hard pressure, but its only production consumer is the reader pool. It blocks new general readers, not product-write admission.
2. The writer loop continues draining and executing queued write batches while hard_drain_required is true. It runs another PASSIVE checkpoint after each batch, but never gates the next batch on drain completion, so every blocked checkpoint can be followed by more WAL growth.
3. The 100 ms CheckpointRetry timer is enabled only in the queue.is_empty() wait branch. Under continuous writes that retry phase is never entered; retries are coupled to post-write checkpoints instead.
4. Automatic checkpoints use latest_blockers, initialized empty and refreshed only when an explicit checkpoint command arrives. The writer does not own the snapshot lease registry, so it cannot refresh blocker identity/age itself. This explains why hard-pressure telemetry can report no blockers even when SQLite is held by an older reader.
5. Runtime telemetry currently projects wal_bytes and the configured budget, but not the writer's CheckpointPressure/latest CheckpointOutcome, blocker inventory, or hard-retry count. A shard can therefore remain ready while observably over hard limit.

This is not safe to patch as a local threshold/checkpoint change. Two contract choices are required first:

• whether product writes at hard pressure remain admitted-and-queued (bounded backpressure), are returned with a new typed WAL-pressure shed result, or transition the shard to typed degraded/faulted after a bounded drain deadline;
• which existing snapshot authority supplies fresh blocker inventory to scheduled retries/status without creating a shadow registry in the writer.

Recommended implementation once those are chosen: gate batch execution whenever hard_drain_required; keep cancellation/authority checks live while queued; refresh blockers from the canonical snapshot authority on each bounded retry; publish pressure/outcome/retry count through PhysicalWriterRuntimeSnapshot; and add the held-reader + continued-write integration test at a tightened valid WAL budget, asserting no silent growth beyond one admitted batch and recovery to <= soft after release.

Leaving #798 open as analyzed/needs runtime contract decision. No limit increase is proposed.