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/smp.md

@@ -23,8 +23,8 @@ INIT–SIPI–SIPI, brings each up into 64-bit long mode with its own descriptor
 LAPIC and timer, and drops it into the scheduler. Tasks run **genuinely in parallel** —
 the `smp` self-test confirms worker tasks executing on all four cores at once under
 QEMU `-smp 4`. Shared kernel state (scheduler queues, IPC) is serialised behind a big
-kernel lock. What's left is refinement, not first-light: per-core run queues, IPIs,
-and thread-to-core affinity (see [Implementation status](#implementation-status)).
+kernel lock. What's left is refinement, not first-light: per-core run queues and IPIs
+(see [Implementation status](#implementation-status)).
 
 ## The common microkernel instinct: don't share kernel state
 
@@ -238,10 +238,12 @@ next lands.
 - **Per-core run queues** — the Fiasco.OC direction, if the single global queue's lock
   contention ever bites. (Thread *affinity* already exists — see above; this is the
   further step of giving each core its own primary run queue for load distribution.)
-- **Fault recovery** — today a fault halts (only) the faulting core. Turning that into
-  "kill the task, keep the core running" is the [resilience](resilience.md) track (it
-  needs the task's lock/resource state handled), and for taking a core fully offline,
-  its tasks migrated first.
+- **Fault recovery** — a ring-3 fault already **kills the faulting process and keeps the
+  core (and the rest of the system) running**: the kernel trapped it on the task's own
+  kernel stack, reclaims what the process held, and reschedules
+  (`process.killCurrentProcess`; the `fault-recovery` test proves init keeps heartbeating
+  through the kill) — the [resilience](resilience.md) track. What's still open here is
+  taking a core fully **offline**, which additionally needs its tasks migrated off first.
 
 ## Further reading