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

@@ -18,7 +18,7 @@ matters for understanding why. This page maps the landscape so the
   new ISA.
 
 They are as different from each other as either is from x86-64: separate registers,
-page-table formats, and calling conventions. Each needs its own `system/kernel/arch/<name>/`.
+page-table formats, and calling conventions. Each needs its own `system/kernel/architecture/<name>/`.
 
 ## The Raspberry Pi models
 
@@ -57,9 +57,9 @@ the DTB/ACPI tells you what devices exist.
 
 ## What danos needs, layer by layer
 
-- **One CPU arch module: `system/kernel/arch/aarch64/`** — covering the Zero 2 W and Pi 3-5,
+- **One CPU arch module: `system/kernel/architecture/aarch64/`** — covering the Zero 2 W and Pi 3-5,
   providing the same `arch` interface as x86_64: `halt`, context switch,
-  interrupt/exception vectors, page tables, a UART, a timer. No `system/kernel/arch/arm/` is
+  interrupt/exception vectors, page tables, a UART, a timer. No `system/kernel/architecture/arm/` is
   planned (see the decision above), so there's a single ARM backend to write.
 - **A device-tree boot path.** Since stock Pis boot via DTB, danos needs an entry
   that parses the DTB's `/memory` and `/reserved-memory` into the neutral
@@ -67,11 +67,16 @@ the DTB/ACPI tells you what devices exist.
   from a different source. This is where keeping boot-protocol knowledge on the
   loader side (as we did for the UEFI memory-map classification) pays off.
 - **The UEFI loader mostly carries over.** `boot/efi.zig` is largely
-  boot-*protocol* code (`std.os.uefi` protocol calls), not x86 code. Its only truly
-  x86-specific bits are the ELF machine check (`.X86_64`) and the SysV calling
-  convention for the kernel jump. So an `aarch64`-UEFI target (QEMU `virt` + AAVMF)
-  can reuse it — which makes **aarch64-UEFI the easiest second target**, easier than
-  the device-tree Pi.
+  boot-*protocol* code (`std.os.uefi` protocol calls), not x86 code. Its truly
+  x86-specific bits are the ELF machine check (`.X86_64`), the SysV calling
+  convention for the kernel jump, the `hlt` park on failure — and, the substantial
+  one, the bootstrap page tables: `buildBootstrapTables` builds x86-64 4-level
+  tables (PML4/PDPT/PD index shifts, x86 PTE bits, 2 MiB leaves) and hands the
+  kernel a CR3. Page-table formats are per-architecture (see above), so an
+  `aarch64` loader keeps the protocol code but rewrites that builder in the
+  aarch64 translation-table format. Even so, an `aarch64`-UEFI target (QEMU
+  `virt` + AAVMF) reuses most of it — which makes **aarch64-UEFI the easiest
+  second target**, easier than the device-tree Pi.
 
 ## Pi hardware quirks (for when we port)