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-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.