docs: full docs-vs-code audit — fix every stale claim across 40 docs

Every doc verified claim-by-claim against the code by parallel audit agents,
then fixed and adversarially re-verified. Two waves of staleness corrected:
the originally audited findings (higher-half boot handoff, kernel VFS
takeover, fault isolation + claim release + driver restart, AML/S5 moving to
ring 3, threading's shipped design, USB+FAT landing) and a second pass of
adjacent claims the verifiers caught (smp.md 'not built yet' intro,
system-requirements' PS/2-only and no-storage claims, halting.md's red-panic
and no-IDT text, testing.md's serial mirroring, router-era vfs-protocol
wording, capsule-first boot loading).

threading.md now documents the shared-fate gap explicitly: the design says a
process dies whole, the kernel today kills only the offending thread.

Also fixes three stale code comments (isr.s exceptionHandler, acpi.zig
sleepValue, build.zig boot-volume) — comments only, no behavior change.

docs/testing.md

@@ -7,10 +7,13 @@ without a human staring at the screen.
 
 There are two layers:
 
-- **Host unit tests** (`zig build test`) — for pure, platform-independent logic in
-  the shared contracts (`system/boot-handoff.zig`, `system/abi.zig`,
-  `system/devices/device-abi.zig`), which also compile-checks the three-way split
-  stays self-consistent. These compile for the host and run natively.
+- **Host unit tests** (`zig build test`) — for pure, platform-independent logic.
+  What began as the three shared contracts (`system/boot-handoff.zig`,
+  `system/abi.zig`, `system/devices/device-abi.zig`) now spans ~26 modules:
+  protocol and on-wire definitions (VFS, USB, virtio-gpu), the FAT engine, the
+  display compositor, PS/2 and HID decoding, the kernel log ring, and the
+  runtime's `time`/`thread` — the full list is the test step in `build.zig`.
+  These compile for the host and run natively.
 - **QEMU integration tests** (`python3 test/qemu_test.py`) — boot the real kernel
   and check its behaviour. This is the interesting part.
 
@@ -18,9 +21,9 @@ There are two layers:
 
 The framebuffer console draws pixels, which a test can't read without
 screen-scraping. So the kernel also writes everything to a **serial port**
-(`system/kernel/architecture/x86_64/serial.zig`, a 16550 UART on COM1). `Console.write` mirrors every
-byte to it, so all kernel output — boot log, memory summary, exception reports —
-appears on serial as plain text.
+(`system/kernel/architecture/x86_64/serial.zig`, a 16550 UART on COM1). The diagnostic log fans out
+to registered sinks, and the serial UART is one of them, so all kernel output —
+boot log, memory summary, exception reports — appears on serial as plain text.
 
 QEMU captures that with `-serial file:serial.log`, giving a machine-readable
 transcript. Serial is per-architecture (x86 uses port I/O; an ARM board uses a
@@ -51,13 +54,18 @@ DANOS-TEST-RESULT: PASS (6 passed, 0 failed)
 DANOS-TEST-DONE
 ```
 
-Current cases:
+The core kernel cases (the suite has since grown far beyond this table — SMP,
+threads, processes, display, USB, FAT and more; the full list is the `CASES`
+table in `test/qemu_test.py`):
 
 | Case | What it checks | How the harness confirms it |
 |------|----------------|-----------------------------|
 | `smoke` | memory map has usable RAM; frame alloc/free; paging active | `DANOS-TEST-RESULT: PASS` |
+| `discovery` | ACPI discovery populated the platform facts: MADT (LAPIC base, CPU count) and FADT (PM/reset registers) | `DANOS-TEST-RESULT: PASS` |
+| `wx` | W^X audit: kernel code is executable; rodata, data, heap, and stack are NX | `DANOS-TEST-RESULT: PASS` |
 | `timer` | device interrupts fire and return (tick count advances) | `DANOS-TEST-RESULT: PASS` |
 | `clock` | LAPIC + TSC calibrated; monotonic uptime advances; `nanos()` has sub-ms resolution | `DANOS-TEST-RESULT: PASS` |
+| `wall-clock` | the CMOS RTC read at boot yields a plausible current epoch | `DANOS-TEST-RESULT: PASS` |
 | `vmm` | on-demand `map` works: a mapped page is writable and reads back | `DANOS-TEST-RESULT: PASS` |
 | `heap` | kernel heap: alloc/free, block reuse, growth, and a std container on it | `DANOS-TEST-RESULT: PASS` |
 | `sched` | preemption: three non-yielding tasks all make progress | `DANOS-TEST-RESULT: PASS` |
@@ -65,11 +73,19 @@ Current cases:
 | `sleep` | a task blocks for ~50 ms (real block, not a busy-wait) | `DANOS-TEST-RESULT: PASS` |
 | `event` | a task blocks on a wait queue and is woken (preempting) | `DANOS-TEST-RESULT: PASS` |
 | `ipc` | producer/consumer pass 100 messages through a 4-slot channel intact | `DANOS-TEST-RESULT: PASS` |
+| `ipc-call` | synchronous IPC: client and server ping-pong 100 calls through one endpoint (rendezvous, reply routing, cross-copy) | `DANOS-TEST-RESULT: PASS` |
+| `ipc-cap` | capability passing: endpoints handed over in a call and its reply arrive as the same object, shared not moved | `DANOS-TEST-RESULT: PASS` |
+| `dma` | DMA memory: contiguous frame allocation, below-4G cap, coherent mapping, reclaim on teardown | `DANOS-TEST-RESULT: PASS` |
+| `msi` | an MSI vector is allocated and delivered as an endpoint notification (a self-IPI stands in for the device write) | `DANOS-TEST-RESULT: PASS` |
+| `iommu` | the VT-d unit is found in the DMAR table and its registers read back (detection only; boots with an emulated IOMMU) | `DANOS-TEST-RESULT: PASS` |
+| `ioport` | port I/O grants: an `io_port` resource admits in-range reads, refuses out-of-range/unclaimed | `DANOS-TEST-RESULT: PASS` |
 | `fault-ud` | invalid-opcode exception is caught | serial shows `invalid opcode (vector 6)` |
 | `fault-pf` | page fault caught with CR2 | `page fault (vector 14)` |
 | `fault-df` | double fault caught on IST1 (not a triple-fault reset) | `double fault (vector 8)` |
+| `fault-ap-df` | a double fault pinned to an application processor is caught by that core's own TSS/IST (boots with `-smp 4`) | `core N: double fault (vector 8)`, N ≥ 1 |
 | `fault-nx` | executing a data page (NX) faults | `page fault (vector 14)` |
 | `fault-null` | dereferencing the unmapped page 0 faults | `page fault (vector 14)` |
+| `fault-recovery` | a ring-3 process that faults is killed and reaped while init keeps heartbeating — the OS survives | `DANOS-TEST-RESULT: PASS` |
 
 The faulting cases don't print a result line — they deliberately raise a CPU
 exception, and the harness asserts on the [exception report](interrupts.md) the
@@ -81,8 +97,10 @@ marker would never appear.
 
 `test/qemu_test.py` ties it together. For each case it:
 
-1. builds the kernel with `-Dtest-case=<name>`,
-2. assembles a fresh EFI System Partition from the built binaries,
+1. builds the kernel with `-Dtest-case=<name>` (the build produces the bootable
+   FAT32 USB image, `zig-out/danos-usb.img`),
+2. copies that image to a fresh per-run boot volume, so the guest's mutations
+   don't dirty the build artifact,
 3. boots it headless in QEMU with serial captured to a file and `-no-reboot`
    (so a triple fault exits rather than looping),
 4. polls the serial log until the case's expected regex appears (**pass**), a
@@ -118,8 +136,8 @@ firmware, boot method, serial device). The cases are architecture-neutral —
 So bringing up a second architecture — an AArch64 Raspberry Pi is the motivating
 one — means:
 
-1. implement `system/kernel/arch/aarch64/` (CPU ops, its UART, exception vectors, page
-   tables) behind the same `arch` interface,
+1. implement `system/kernel/architecture/aarch64/` (CPU ops, its UART, exception vectors, page
+   tables) behind the same `architecture` interface,
 2. add an `aarch64` entry to `ARCHES` with its `qemu-system-aarch64` invocation,
 
 and the *same* `smoke` / `fault-*` cases run against it: `python3 test/qemu_test.py