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/devices-csv.md

@@ -1,6 +1,6 @@
-# /etc/devices.csv — the device registry
+# /system/configuration/devices.csv — the device registry
 
-**Status: built (2026-07-26).** The device manager reads `/etc/devices.csv` at
+**Status: built (2026-07-26).** The device manager reads `/system/configuration/devices.csv` at
 boot and binds every device a bus driver reports to the driver the registry
 names. It replaces the three hand-written `switch` tables that used to live in
 the manager (`pciDriverForIdentity`, `hidDriverFor`, `usbDriverForIdentity`) —
@@ -73,15 +73,15 @@ the first, so the shadowed rule is visible rather than silently dropped.
 
 There is no compiled-in default table behind the registry. A device that no row
 matches goes **unbound** and is logged; the manager never guesses. A missing or
-empty `/etc/devices.csv` therefore means nothing matches — which is loud at boot,
+empty `/system/configuration/devices.csv` therefore means nothing matches — which is loud at boot,
 not a silent half-working system.
 
 ## How the manager reads it
 
-`/etc/devices.csv` is bundled into the initial ramdisk (`build.zig`'s `bundled`
-list). The kernel serves the initrd's `/etc` tree directly — the `fat` service is
-spawned *after* the device manager and is irrelevant to `/etc` — so the manager
-reads the file with a plain `fs.open("/etc/devices.csv")` + `read`, with no
+`/system/configuration/devices.csv` is bundled into the initial ramdisk (`build.zig`'s `bundled`
+list). The kernel serves the initrd's `/system/configuration` tree directly — the `fat` service is
+spawned *after* the device manager and is irrelevant to `/system/configuration` — so the manager
+reads the file with a plain `fs.open("/system/configuration/devices.csv")` + `read`, with no
 filesystem service running and no boot-ordering dependency. It parses the bytes
 once in `initialise`, before any bus driver can report a device to match.
 
@@ -105,6 +105,6 @@ in different namespaces — against the right `bus` column.
    `build_support.programModule`). Then bundle it at `/system/drivers/<name>`:
    one dependency + one bundled entry in the root `build.zig`, one line in the
    root `build.zig.zon`.
-2. Add a row to `etc/devices.csv` naming the identity it binds and its full path.
+2. Add a row to `system/configuration/devices.csv` naming the identity it binds and its full path.
 
 No device-manager change is required — the registry is the seam.