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