docs: storage — the mount map is built; the path is the id (S2)

Flip the storage docs to match S2: filesystems.csv (signature -> binary) and
volumes.csv (identity -> optional override) are built; a volume's mount path IS
its content id (/volumes/<id>), never a port name; the label is display metadata
a `volumes` query returns. fat receives its mount path via argv[2] rather than
hardcoding it. Still pending: rung 2 (filesystem UUID, needs a non-FAT engine),
multi-volume (fat's boot rewrites stay unconditional until S3), medium_changed
consumption, remount bench-verification.

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

@@ -218,9 +218,10 @@ matrix-proven shape; genuinely open.
    **content identity, never port or discovery order**. Build status: rungs 1,
    3, and 4 (GPT partition GUID, FAT serial + label, MBR signature + index) are
    implemented (S1); rung 2 waits on a non-FAT engine. The `volumes.csv` map and
-   the id-derived mount path land with S2, so today a single volume still mounts
-   at the fixed `/volumes/usb` and its recorded identity is not yet consulted to
-   pick a path. The ladder the prober reads off the medium, strongest first:
+   the id-derived mount path are built (S2): a volume's mount path IS its content
+   id (`/volumes/<id>`, e.g. `/volumes/fat-12345678`), or a `volumes.csv`
+   override; the label is display metadata a `volumes` query returns, never the
+   path. The ladder the prober reads off the medium, strongest first:
    1. GPT partition GUID — 128-bit, unique, stable for the volume's life — **built (S1)**;
    2. filesystem UUID (ext-family and most modern formats, in the superblock) *(planned)*;
    3. FAT volume serial + label — 32 bits, weak (dd-cloned sticks share it)