docs: correct the storage docs' V0-V4 status — the V5 flip missed several

A V5 close-out audit (docs against the actual code) found the storage docs
overclaiming in both directions: the status header was flipped to "built" but
several body markers were not, and two passages describe mechanisms the code
never implemented. Nine confirmed, adversarially verified against the source:

Underclaims (marked Planned, actually built):
- storage-architecture: driver named sub-ranges / range confinement (V2, tested
  by the block-range case); the pushed medium_changed event (published today
  from a TEST UNIT READY poll); ownership-gated fs_unmount (V0, process.zig
  gates it with EPERM); the filesystem-harness extraction (V1). Scoped the
  remaining *planned* to the genuinely-pending parts (native-signal translation,
  the volume manager consuming medium_changed).

Overclaims (described, never built):
- storage-architecture: the "FAT dirty flag on disk" guarantee — no on-disk
  dirty/clean-shutdown bit exists; only an in-memory device-dirty bool gating a
  device write-cache flush on close. Fixed in all three places.
- storage-architecture: fat "acquires its own volume (first mass-storage child
  by enumeration order)" — the V3b flip removed self-acquisition; fat is handed
  its volume id and channel by the volume manager.
- rationale + plan: the FAT engine's base_lba "deleted rather than moved" — it
  and the engine's MBR walk still exist as now-inert legacy; the authoritative
  walk lives in partition.zig.
- rationale: NVMe namespaces "decision 4 settles as endpoint-per-volume" —
  decision 4 settles the opposite (per-sender confinement, one endpoint);
  endpoint-per-volume is named only as an unbuilt future refactor.
- rationale: the five-rung identity ladder and volumes.csv map stated in flat
  present tense — only rung 4 (MBR signature + index) is built; added the
  build-status hedge and marked each rung.

Docs only; no code or behavior change. Suite unaffected (127/127).

docs/volume-manager-plan.md

@@ -12,8 +12,10 @@ range confinement at the provider on one serving endpoint — the badge-scoped
 provider pattern the xHCI bus already uses, applied to blocks. The volume
 manager sets each filesystem process's range; the driver clamps and translates
 every transfer by the sender's kernel-stamped badge; filesystems address
-volume-relative LBAs from 0 and the FAT engine's `base_lba` is deleted rather
-than moved. Every other decision the phases below execute is recorded in the
+volume-relative LBAs from 0 (on the confined path the FAT engine's `base_lba`
+resolves to 0; the field and the engine's own MBR walk remain as now-inert
+legacy, the authoritative walk living in the volume manager's `partition.zig`).
+Every other decision the phases below execute is recorded in the
 rationale (decisions 1–8); nothing in this plan waits on a choice.
 
 ## V0 — `fs_unmount` ownership (the defect fix)