docs: transport generality and the media-presence event

The NVMe/SATA assessment folded into the storage discussion: what transfers
untouched (the block contract and everything above it — one driver binary
plus one devices.csv row per transport), NVMe as the shorter stack whose
namespaces are the reserved multi-volume case, AHCI as an open shape choice
(leaning per-port processes, the matrix-proven granularity), and the three
pressure points named honestly: multi-volume is reserved-not-implemented,
synchronous call/reply bottlenecks NVMe until the shm-ring data plane, and
media lifecycle is not device lifecycle.

That last one becomes decision 7 and enters the architecture doc: the
removal path has TWO TRIGGERS, ONE LIFECYCLE — channel death (device leaves)
and a planned pushed medium_changed event (medium leaves, device stays: card
readers and trays, USB ones today), translated by the storage driver from
its transport's native signal, presence never content, consumed by the
volume manager into the same kill-retire-remount path. Without it a swapped
card would be served with the previous card's filesystem state.

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

@@ -56,9 +56,11 @@ Three kinds of boundary, deliberately different:
 reports children to the device manager, serves the transfer contract to its
 own children's class drivers, routed by lineage.
 
-**Storage driver** (usb-storage, per device): hardware → blocks. Speaks SCSI
-Bulk-Only Transport upward from its device; serves the block protocol (five
-verbs: geometry, read, write, flush, attach). **Content-blind, permanently**:
+**Storage driver** (usb-storage, per device; later nvme, ahci): hardware →
+blocks. Speaks its transport upward from its device; serves the block
+protocol (geometry, read, write, flush, attach, detach — and, *planned*, the
+pushed `medium_changed` presence event, translated from the transport's
+native signal). **Content-blind, permanently**:
 it reads block 0 only as a bring-up self-check and parses nothing — no MBR, no
 GPT, no filesystem magic, ever. *(Planned)* it gains one content-blind
 mechanism: **named sub-ranges** — "serve blocks [a, b) as a channel of the
@@ -137,6 +139,17 @@ surprise-removal path — kill the filesystem process, retire its mounts,
 respawn on return. No half-alive states, no `remount-ro`, no mounts that
 error forever (Plan 9's dead-server wart).
 
+The path has **two triggers, one lifecycle**: the *device* leaving (the
+storage driver dies — channel death, the table below), and the *medium*
+leaving while the device stays (an SD card pulled from its reader, an ATAPI
+tray opened — including USB card readers today). The second trigger is a
+pushed `medium_changed` event on the block protocol *(planned)*: the storage
+driver translates its transport's native signal (SCSI UNIT ATTENTION, AHCI
+PxSSTS, NVMe namespace-change AER) into presence-changed — never content —
+and the volume manager runs the same kill-retire path, then re-probes on
+medium return exactly as on device return. Without it, a swapped card would
+be served with the previous card's filesystem state.
+
 | Layer | Observes | Must do | Guarantees |
 |---|---|---|---|
 | Bus driver | port/hub status change | tear down the device's slots (children first, recursively — built, hot-plug matrix), report `child_removed` per interface | the device tree is honest within one reconcile tick |