Adds a prototype v3 blob store with registry ledger accounting under crates/aft/src/blob_store/v3.rs. Writers serialize at the storage root before taking a registry transaction; ledger reads never enter that lock order, sharing identity-tracked SQLite connections in-process or using SQLITE_OPEN_READ_ONLY across processes. Bootstrap publishes schema, application ID, seeds, and format marker in one SQLite transaction and resumes only empty exact-schema prefixes.
Reservations bind to canonical registry/file identity; root-locked recovery reclaims dead reservations, cross-family releases are rejected before any mutation, and task-GC sweeps stay scoped under the storage floor so cleanup cannot bypass it.
One most-specific owner rule (normalized roots, fewest child components) decides refusal recording, lookup, floor gates, inventory, status push, and cleanup, with a lexical direct-owner pass to skip alias probes; relocated-cache symlinks/junctions and aliased caller paths all reach the same refusal, and prepare/raise register roots in memory.
persisted_format refuses incompatible stores with typed IncompatibleReason; migrate_storage omits rebuildable blobs/v3 from sizing/copying and reports retained source is deletable.
DurabilityStep gains two v3-only boundaries; the eight v2 kill cases are preserved via ALL-minus-V3_ONLY assertion.
Tests cover cross-process admission, child-process kills, inode-alias/readonly-first handoff, path-alias and task-GC floor refusal lookups, and VFS audits proving no out-of-band content access.
Confidence Score: 5/5
The PR appears safe to merge; no new blocking issue was found.
Summary
Adds a prototype v3 blob store with reservation accounting, read-only ledger access, and recovery after interrupted writes.
V3 blob writes reserve space and keep payload reads separate.
Format refusals follow the storage root that owns each file.
Storage migration leaves the rebuildable v3 subtree at its source.
No new actionable issues were found in the changes since the previous review. All supplied previous threads were unnumbered and were checked as context.
Diagram
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Publication request] --> B[Read-only space check]
B --> C[Persist reader floor]
C --> D[Acquire storage-root lock]
D --> E[Recover abandoned reservations]
E --> F[Check limits and reserve space]
F --> G[Write and flush plane data]
G --> H[Commit ledger charge]
I[Ledger reader] --> J[Shared or read-only SQLite connection]
J --> K[Read accounting without root lock]
