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/process-management.md

@@ -14,7 +14,7 @@ process-manager server, and Fuchsia/seL4 control processes only through handles.
 
 danos rules out `/proc` **as the primitive**: the path router lives in the
 kernel (`fs_resolve`), but what is mounted under a path is served by a
-user-process filesystem server (the way FAT serves `/mnt/usb`) — a `/proc`
+user-process filesystem server (the way FAT serves `/volumes/usb`) — a `/proc`
 would be one more such server, which would put a user process in the path of
 process control. If that server (or anything under it) hangs, nothing could be
 listed or killed, *including the hung server*. The control plane for processes
@@ -117,9 +117,11 @@ the architecture layer calls up into `tick`.
   `process_exit_reason` (`process.exitReason`). This is the input to
   restart policy ([process-lifecycle.md](process-lifecycle.md)); an exit *code*
   for the clean case can still ride alongside later.
-- Enumerate writes through the caller's raw pointer under the bring-up trust
-  model, like `device_enumerate` (an unmapped page is a self-DoS, not an
-  isolation break).
+- ~~Enumerate writes through the caller's raw pointer under the bring-up trust
+  model, like `device_enumerate`~~ Closed (8d4a7cf): both `process_enumerate`
+  and `device_enumerate` describe a chunk into a kernel buffer and place it with
+  `copyToUser`, which validates the range and resolves each page — an unmapped
+  page returns `-EFAULT`, and the kernel never stores through the user pointer.
 
 ## Tests