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/usb-hub.md

@@ -29,8 +29,9 @@ full-speed keyboard.
 
 ## Slot-context fields for a downstream device
 
-`buildAddressInputContext` fills the Slot Context. Today it hardcodes route 0 and
-the root-hub port. A downstream device additionally needs:
+`buildAddressInputContext` fills the Slot Context from the device record: a
+root-port device carries route 0 and its own root-hub port. A downstream device
+additionally carries:
 
 - **Route String** (Slot Context dword 0, bits 19:0) — 5 tiers × 4 bits, each
   tier the downstream hub-port number. Composed as
@@ -80,10 +81,12 @@ When the bus scan (or a hot-plug bring-up) finds a device of class 9:
 
 ## Testing
 
-QEMU's `usb-hub` is a USB 2.0 single-TT hub. A **static boot topology**
-(`-device usb-hub,bus=xhci.0,id=h -device usb-kbd,bus=h.0`) presents the
-downstream device connected from the start, so the bus reads it on the first
-status-change report — exercising the full path (hub setup, TT slot context,
+QEMU's `usb-hub` is a USB 2.0 single-TT hub. A **static boot topology** on a
+dedicated second controller (`-device qemu-xhci,id=xhci2 -device
+usb-hub,bus=xhci2.0,port=1 -device usb-kbd,bus=xhci2.0,port=1.1` — isolated from
+the boot controller's auto-assigned devices, whose ports the hub would collide
+with) presents the downstream device connected from the start, so the bus reads
+it on the first status-change report — exercising the full path (hub setup, TT slot context,
 downstream enumerate, class-driver bind) without needing a hot-plug event. A new
 `usb-hub` QEMU case asserts the hub enumerates, the downstream keyboard
 enumerates behind it, and `usb-hid-keyboard` binds.