docs: flip stale status markers across the tracks (audit found 23)

An all-tracks docs-vs-code audit (the same method that caught the storage
drift) found 23 confirmed inaccuracies where a doc's build-status claim no
longer matches the source — status markers that were never flipped after a
track landed, and a few paths left over from completed flag-days. All verified
against the code before editing; docs only, no behavior change.

The systemic ones:
- IOMMU enforcement (driver-model.md, drivers.md): docs said enforcement was
  not built and "device_claim = ring 0" / "memory-safe is not true yet". It is
  built (per-device VT-d/AMD-Vi domains programmed at device_claim, -ECONFINE
  rollback, dma_alloc buffers bound and torn down at death; fail-open only with
  no IOMMU). Restated; M16 marker flipped to done.
- The FHS flag-day paths: /etc/devices.csv -> /system/configuration/devices.csv
  (devices-csv.md, new-driver-checklist.md, device-manager.md), /var/log ->
  /system/logs (logging.md, new-driver-checklist.md), /mnt/usb -> /volumes/usb
  (process-management.md). Following the old paths silently breaks driver match.
- protocol-namespace P4 "remaining" -> landed (only P5 remains); shared-fate
  fan-out "not yet enforced" -> enforced; wall_clock "not built" -> built;
  SMP affinity + fault-recovery "left" -> built; process_enumerate raw-pointer
  trust model -> checked copyToUser/EFAULT; bounds.md maximum_devices static
  hole -> dynamic per-registrar quota; init spawns fat -> volume-manager;
  config "hardcoded, move to /etc" -> already CSV data files; vdso.md three-
  value call; zig-self-hosting library/ layout; python argv "new" -> built.

Found and fixed by a multi-agent audit across 12 doc clusters, each finding
adversarially verified against the source.

docs/device-driver-development/drivers.md

@@ -32,7 +32,7 @@ kernel  ──spawns──►  init (PID 1)  ──spawns──►  device-manag
   spawns only init,     the service supervisor:    the driver supervisor: enumerates
   publishes the         starts the system          /system/devices, matches each device
   initial-ramdisk       services (device-manager,  to a driver, and system_spawn's it
-  so user space can     fat, logger, ...). Its
+  so user space can     volume-manager, logger, ...). Its
   system_spawn from it  list is init policy.
 ```
 
@@ -43,7 +43,7 @@ the optional arguments its argv[1..], on a SysV entry stack, see sysv.md). Every
 
 - **init** ([system/services/init](system/services/init/init.zig)) is the **service
   supervisor**. It spawns the system services danos brings up at boot — today `input`,
-  the `device-manager`, `fat`, `display`, `display-demo`, and the `logger` — from a
+  the `device-manager`, `volume-manager`, `display`, `display-demo`, and the `logger` — from a
   small list. Drivers are deliberately *not* its job. (An earlier draft listed a `vfs`
   service here; that service is retired — the router moved into the kernel as
   `fs_resolve`.)
@@ -66,9 +66,10 @@ the optional arguments its argv[1..], on a SysV entry stack, see sysv.md). Every
 
 So "how is a driver discovered and configured" has two halves: **discovery** is the
 kernel's device table, read by anyone; **configuration** is two user-space policies —
-init's service list and the device-manager's match table. Both are hardcoded in their
-respective programs today; the natural next step is to move them into `/etc` (see the
-milestone notes in [driver-model.md](driver-model.md)). `system_spawn` is currently
+init's service list and the device-manager's match table. Both are now data, not code —
+init reads `/system/configuration/init.csv` and the device manager reads
+`/system/configuration/devices.csv`, each parsed at startup (the compiled-in switch
+tables are gone). `system_spawn` is currently
 ungated — any process may spawn any bundled binary — because there is no spawn
 capability yet.
 
@@ -301,12 +302,13 @@ process releases its claims and IRQ/MSI bindings — `releaseAllOwnedBy`,
 - **Page granularity.** `mmio_map` rounds to 4 KiB. Two devices sharing a page means
   granting one grants the other. A `device_register`ed child's *resource* can be narrower
   than a page, but its *mapping* can't.
-- **DMA is not contained.** A driver that can program a bus-mastering device can make
-  that device write to *any* physical address — page tables don't sit between a device
-  and RAM; an IOMMU does. The IOMMU is now *detected* (M16), but no translation domains
-  are programmed, so `device_claim` on a DMA-capable device is still effectively
-  equivalent to granting ring 0. This is the largest gap between the design's promise and
-  what it delivers; enforcement lands with the first DMA driver.
+- **DMA is contained — except on a machine with no IOMMU.** A driver that can program a
+  bus-mastering device could make that device write to *any* physical address — page
+  tables don't sit between a device and RAM; an IOMMU does. `device_claim` now confines
+  each claimed PCI function into its own VT-d/AMD-Vi translation domain and rolls the
+  claim back with `-ECONFINE` if it can't (`system/kernel/process.zig`); DMA buffers are
+  bound into that domain and torn down at process death. The residual gap is fail-open:
+  where the machine exposes **no IOMMU at all**, a DMA-capable claim still reaches RAM.
 - **No voluntary `dev_release`.** A *live* driver can't drop a claim — only exit
   releases it (any path out of a process runs `releaseAllOwnedBy`) — so handing a
   device between running drivers still means exiting.
@@ -365,10 +367,9 @@ $ python3 test/qemu_test.py device-manager acpi-ps2 pci-scan containment irqfree
 ## What's next (not done here)
 
 The big driver-model pieces — capability passing (class drivers), DMA + barriers, MSI,
-and IOMMU detection — are **now done** ([driver-model.md](driver-model.md), M13–M16), as
-is **port I/O** (`io_read`/`io_write`, the claim-gated syscalls that make a PS/2 or 16550
-driver possible). What's left is IOMMU *enforcement* (per-device domains — it waits on
-the first DMA driver to protect and test against) and these smaller items:
+and per-device IOMMU confinement — are **now done** ([driver-model.md](driver-model.md),
+M13–M16), as is **port I/O** (`io_read`/`io_write`, the claim-gated syscalls that make a
+PS/2 or 16550 driver possible). What's left is a handful of smaller items:
 
 - **Releasing a claim** — half done. The kernel now drops *all* of a dead driver's
   claims on every path out of a process (`releaseAllOwnedBy`, called from process