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/frame-allocator.md

@@ -118,17 +118,22 @@ regions `init` frees. Keeping that boot-protocol knowledge on the loader side is
 deliberate — the kernel has no notion of "reclaimable" or of UEFI at all.
 
 The one live piece in that memory is the boot stack the kernel starts on; the loader
-leaves the single region containing it `reserved`, so `init` won't hand it out. A
-later step will move task 0 onto a kernel-owned stack, freeing that last ~1 MiB
-region too (and giving user mode the clean stack it wants).
+leaves the single region containing it `reserved`, so `init` won't hand it out. The
+kernel is only on it for an instant, though — `_start`'s first instruction switches
+to a kernel-owned 64 KiB stack in `.bss` (that context becomes task 0). The region
+stays `reserved` because the loader's own `convertMemoryMap` was executing on that
+stack when it reclassified the RAM, and, like the map buffers below, nothing frees it
+yet.
 
 ## What's next (partly done since)
 
 - **Contiguous allocation** — done: `allocContiguous` scans for a run of clear
   bits, with an optional physical ceiling for DMA (`dma_alloc` is its user), and
   `allocBelow` serves the SMP trampoline.
-- **A kernel stack for task 0** — still open: the boot processor's idle task runs
-  on the boot stack to this day, so that region can't be freed.
+- **A kernel stack for task 0** — done: `_start`'s first instruction switches `rsp`
+  to a kernel-owned 64 KiB stack in `.bss` (`bootstrap_stack`), and `scheduler.init`
+  registers that running context as task 0 — the kernel is on the loader's boot
+  stack for that one instruction and never again.
 - **Freeing the `reserved` `loader_data`** (the boot-time map buffers) — still
   open: the bitmap deliberately tracks those frames so they *can* be freed, but
   nothing frees them yet.