docs: multi-volume is built — storage architecture + rationale (S3)

Flip the storage docs from "one FAT volume today" to the built state:
the manager adopts every device, probes each device's whole partition
table, and spawns one range-confined FAT per volume — several volumes
across several devices, or several partitions on one device's channel.
The boot volume is identified by content; a filesystem installs the
/system rewrites only when it resolves /system/configuration on its own
media. No filesystem binds a shared service name any more — clients route
through the kernel mount table.

Correct two now-stale claims in the rationale, in the honest direction:
"multi-volume providers are reserved, not implemented" becomes built
(multi-namespace-per-provider is the untried NVMe case); and the cloned-
duplicate "second mounts suffixed" was never built — S3 mounts both,
they collide on the shared content id-path (last wins), each boot claim
logged, and distinguishing them is S4 arbitration.

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

@@ -145,9 +145,13 @@ matrix-proven shape; genuinely open.
 
 **The pressure points, honestly:**
 
-1. **Multi-volume providers are reserved, not implemented.** The volume
-   manager flow assumes one provider, one volume; NVMe namespaces make
-   endpoint-per-volume real work with hardware demanding it.
+1. **Multi-volume is built; multi-namespace-per-provider is untried.** The
+   volume manager adopts every device and spawns one range-confined FAT per
+   partition — several volumes across several devices, or several partitions
+   sharing one device's channel, both proven on USB. What is untried is a single
+   provider exposing several volumes as *namespaces* (NVMe): the endpoint and
+   per-badge range machinery generalizes, but no such driver exists yet to
+   exercise it.
 2. **The current transport will bottleneck NVMe.** Synchronous call/reply,
    one operation in flight, one bounce buffer — fine for a USB2 stick,
    forfeits an NVMe drive's queue depth and per-queue MSI-X. Correctness
@@ -233,13 +237,15 @@ matrix-proven shape; genuinely open.
    Consequences, each mechanical once identity keys the map: **moving a drive
    to a different port changes nothing** — same identity, same mount point,
    whether USB port, hub depth, SATA port, or a stick that left as USB and
-   returned in a SATA dock; **replug remounts at the same path** (a map lookup
-   once the map exists; today's single volume re-probes and remounts at the
-   fixed prefix, and remount-on-replug is bench-verified, not QEMU-tested); **the boot volume** is the
-   recorded identity of the volume carrying `/system/configuration`, findable
-   on any port; and **duplicate identity is a policy case, not a surprise** —
-   two cloned sticks at once: first keeps the mapped name, second mounts
-   suffixed and is logged loudly, never silently shadowed. Unknown identities
+   returned in a SATA dock; **replug remounts at the same path** (the id-path is
+   content-derived, so a volume returns to `/volumes/<id>` wherever it reappears;
+   remount-on-replug end-to-end is bench-verified, not QEMU-tested, because QEMU
+   can't re-present the boot-controller device); **the boot volume** is the volume
+   that resolves `/system/configuration` on its own media, findable on any port or
+   partition; and **duplicate identity is a known S4 gap** — two cloned sticks
+   share one content id, so today they collide on `/volumes/<id>` (the kernel
+   remount-replaces; the last wins) and each boot-volume claim is logged loudly.
+   Distinguishing them with a suffix is arbitration, deferred to S4. Unknown identities
    mount under a derived name (sanitized label, else generated) at
    `/volumes/<name>` — the hierarchy's documented home for attached media,
    which stands: `/system` is what danos IS; attached media is what it isn't.