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/os-development/logging.md

@@ -14,7 +14,7 @@ are mirrored to it explicitly (`system/kernel/kernel.zig`).
 ## The pipeline
 
 ```
-process std.log ──▶ debug_write(level) ──▶ tagged kernel ring ──▶ logger service ──▶ /var/log/<boot-stamp>/<binary-path>.log
+process std.log ──▶ debug_write(level) ──▶ tagged kernel ring ──▶ logger service ──▶ /system/logs/<boot-stamp>/<binary-path>.log
 kernel log.print ─┘                            │
                                                └▶ serial / 0xE9 sinks (QEMU, -Dserial)
 ```
@@ -49,12 +49,12 @@ kernel log.print ─┘                            │
 
 5. **Persist.** The **logger service** (`system/services/logger`) drains the
    ring every 250 ms and demultiplexes records into one file per source under
-   `/var/log/<boot-stamp>/`, e.g.
+   `/system/logs/<boot-stamp>/`, e.g.
 
    ```
-   /var/log/2026-07-21T150434Z/kernel.log
-   /var/log/2026-07-21T150434Z/system/services/fat.log
-   /var/log/2026-07-21T150434Z/system/drivers/usb-storage.log
+   /system/logs/2026-07-21T150434Z/kernel.log
+   /system/logs/2026-07-21T150434Z/system/services/fat.log
+   /system/logs/2026-07-21T150434Z/system/drivers/usb-storage.log
    ```
 
    The boot stamp is the RTC anchor from `klog_status` (FAT-safe: no colons; a
@@ -95,6 +95,6 @@ written last so a reader only trusts a complete record).
 - A write-spamming process can evict other processes' unread records from the
   ring (a per-process quota is future work); the loss is at least visible via
   sequence gaps in every affected file.
-- `/var/log` files have no privacy until the VFS grows permissions.
+- `/system/logs` files have no privacy until the VFS grows permissions.
 - Records emitted after the logger's final shutdown drain reach serial and the
   ring but not the files.