docs: volume identity, and volumes.csv as danos's fstab

Decision 8 in the rationale, mirrored into the architecture's volume-manager
section: the mount map keys on CONTENT identity, never port or arrival order
— Linux's /dev/sda1-era fstab broke on every port move until UUID= replaced
it, and danos skips that era. The identity ladder the prober reads off the
medium: GPT partition GUID, filesystem UUID, FAT serial+label, MBR
signature+index, anonymous. Consequences are mechanical: port moves change
nothing (USB, hub, SATA bay, or transport swaps), replug remounts at the
same path, the boot volume is a recorded identity findable anywhere, and
cloned duplicates are a loud policy case instead of silent shadowing.
/volumes/<name> stands as the hierarchy's home for attached media; minting
identifiers (formatting, entropy) stays deliberately out of scope.

docs/file-system-development/storage-architecture.md

@@ -83,9 +83,20 @@ policy), enforced by nobody else:
 
 - `filesystems.csv` — content signature → filesystem binary. Adding a
   filesystem adds a row.
-- the mount map — volume identity → mount prefix. The boot volume is chosen
+- `volumes.csv` — the mount map, danos's fstab: **volume identity → mount
-  by **content** (the volume carrying `/system/configuration` and
+  prefix**, keyed on content identity and never on port, path, or arrival
-  `/system/logs`), never by port or arrival order.
+  order (the lesson of Linux's `/dev/sda1`-era fstab, which broke on every
+  port move until `UUID=` replaced it). Identity is read off the medium by
+  the prober, strongest first: GPT partition GUID → filesystem UUID → FAT
+  serial + label → MBR signature + partition index → anonymous (generated
+  name, no persistence). Same identity, same mount point: a drive moved to
+  another port — USB to another hub, SATA to another bay, even a stick
+  returning in a different dock — lands exactly where it was. Duplicate
+  identity (cloned sticks, together) is policy: first keeps the name, the
+  second mounts suffixed and is logged loudly. The boot volume is the
+  recorded identity of the volume carrying `/system/configuration` and
+  `/system/logs`, findable on any port. Unknown volumes mount under
+  `/volumes/<derived name>`.
 
 **Filesystem service** (the FAT service today; one process per volume): the
 proven unit — block-client + engine + file-protocol provider in one binary. It

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

@@ -194,3 +194,32 @@ matrix-proven shape; genuinely open.
    leaves is the one removable-media case the channel-death trigger cannot
    see; without this event a swapped SD card would be served with the old
    card's filesystem state.
+8. **Volume identity, and the mount map as danos's fstab** (settled). The
+   lesson is Linux's own history: fstab keyed on `/dev/sda1` for years and
+   broke whenever a drive changed ports or enumeration order; `UUID=` entries
+   exist because device-path identity failed. danos skips that era: the mount
+   map (`volumes.csv` — configuration, read by the volume manager) keys on
+   **content identity, never port or discovery order**. The prober reads
+   identity off the medium, strongest first:
+   1. GPT partition GUID — 128-bit, unique, stable for the volume's life;
+   2. filesystem UUID (ext-family and most modern formats, in the superblock);
+   3. FAT volume serial + label — 32 bits, weak (dd-cloned sticks share it)
+      but what real sticks carry;
+   4. MBR disk signature + partition index;
+   5. nothing — an anonymous volume: generated mount name, no persistence.
+
+   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** (the
+   remount-after-return story is a map lookup); **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
+   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.
+   danos never needs to MINT identifiers to detect volumes — detection only
+   reads — until it grows formatting, which brings the entropy question and
+   is deliberately out of scope here.