docs: the storage architecture — layers, boundaries, and who does what when media leaves

The settled shape from the storage-stack discussion, written as the
reference: the data path (vfs -> filesystem service -> block -> driver) as
the application/service/protocol/driver model applied twice; the three kinds
of boundary (protocol between processes, library inside them, control-plane
beside them); the volume manager as the policy home (planned — the FAT
service squats on its duties today, marked as such); adding a filesystem as
engine + shared harness + one configuration row; and the per-layer
responsibility table for removable media — one removal path, kill/retire/
respawn, dirty data lost and SAID to be lost. Indexed from docs/README.md.

docs/README.md

@@ -51,7 +51,11 @@ rather than restate it. Roughly in the order things happen at runtime:
 14. **[vfs-protocol.md](file-system-development/vfs-protocol.md) — the VFS wire protocol.** The language-neutral
     byte-level spec of the file protocol spoken over IPC: request/reply headers,
     the operation table, mount routing, and the append-only evolution rules — the
-    first IPC protocol documented as public ABI.
+    first IPC protocol documented as public ABI. Its architectural frame is
+    **[storage-architecture.md](file-system-development/storage-architecture.md) — the storage stack**:
+    the layers from application to hardware, the three kinds of boundary
+    (protocol, library, control-plane), how to add a filesystem, and the
+    per-layer responsibilities when removable media is yanked and returned.
 15. **[drivers.md](device-driver-development/drivers.md) — writing a driver.** The payoff: a driver is an
     ordinary ring-3 process that claims a device, maps its registers, and **sleeps
     until its hardware interrupts it**. The claim is the capability; `irq_ack` is the