docs: decision 4 settled — a loop with an open decision is not a loop

Per-sender range confinement at the provider, one serving endpoint: the
badge-scoped provider pattern the xHCI bus already uses (the per-client
device-token table), applied to blocks. Endpoint-per-volume would buy the
same enforced property only by inventing a multi-endpoint harness; it stays
available as a future refactor, same wire contract. The plan's flag-for-veto
is gone: nothing in the track waits on a choice.

docs/file-system-development/storage-design-rationale.md

@@ -172,11 +172,21 @@ matrix-proven shape; genuinely open.
 3. **One filesystem process per volume** (fat's binary becomes "the FAT
    implementation", spawned per FAT volume). Recommendation: yes — it extends
    recompile-and-restart-live to filesystems and isolates corrupt media.
-4. **Sub-range addressing**: `target` ids on the storage endpoint versus one
-   endpoint per volume handed out by the driver. Endpoint-per-volume matches
-   the establishment-plane machinery (a channel per party, caps at
-   establishment) and keeps per-client badge scoping simple. Recommendation:
-   endpoint per volume.
+4. **Sub-range addressing — SETTLED as per-sender confinement at the
+   provider, one serving endpoint.** The deciding argument is precedent: the
+   xHCI bus already serves every class driver on one endpoint with authority
+   scoped by the kernel-stamped badge (the per-client device-token table) —
+   that IS danos's provider pattern, and per-badge range confinement is the
+   same pattern applied to blocks. The volume manager sets each filesystem
+   process's range on the driver; the driver clamps AND translates every
+   transfer by the sender's range, so filesystems address volume-relative
+   LBAs from 0 and the FAT engine's `base_lba` is deleted rather than moved.
+   The enforcement point (the clamp at the provider, never in the consumer)
+   is what carries the security property; endpoint-per-volume would deliver
+   the same property only by inventing a multi-endpoint harness the pattern
+   does not need. It stays available as a future refactor if a multi-endpoint
+   harness ever exists for other reasons; the wire contract is identical
+   either way.
 5. **`fs_unmount` ownership** — a defect fix more than a decision.
 6. **Later, kept open**: the shm-ring data plane (communication.md already
    names it as the 256-byte ceiling's unlock — Fuchsia's FIFO+VMO is the

docs/volume-manager-plan.md

@@ -7,22 +7,14 @@
 green at phase boundaries, every new test shown to fail against the old
 behavior, one QEMU suite at a time, work on main.*
 
-**One refinement of decision 4, flagged for sign-off rather than silently
-applied.** The decision said endpoint-per-volume. The service harness serves one
-endpoint per process, and kernel-ipc has no wait-on-many; a driver serving N
-range endpoints would need threads or a multi-endpoint harness — real machinery,
-none of it needed for the security property. The property ("a channel carries
-exactly the authority it grants") is delivered instead by **per-sender range
-confinement**: every packet already arrives with the kernel-stamped,
-unforgeable badge; the storage driver keeps a per-badge range (set by the
-volume manager, which spawned the filesystem process and knows its id) and
-clamps-and-translates every transfer by the sender's range. A filesystem
-process addresses volume-relative LBAs from 0; the provider adds the base —
-offset translation at the provider, exactly the Fuchsia session-mapping shape,
-and the FAT engine's `base_lba` code is deleted rather than moved.
-Endpoint-per-volume can still arrive later with a multi-endpoint harness; the
-wire contract does not change either way. **If this refinement is wrong, say so
-before V2.**
+**No open decisions.** Decision 4 is settled in the rationale as per-sender
+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
+rationale (decisions 1–8); nothing in this plan waits on a choice.
 
 ## V0 — `fs_unmount` ownership (the defect fix)