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

@@ -5,7 +5,7 @@ window server, a logger. None of them owns the hardware, and the driver should n
 who is listening. So between the drivers and the listeners sits the **input service**
 (`system/services/input/`): drivers **publish** events to it, programs **subscribe**, and
 it fans each event out to every interested subscriber. It is an ordinary ring-3 process
-reached over IPC, like the [VFS server](../system/services/vfs/vfs.zig) — no kernel knows
+reached over IPC, like the [FAT server](../system/services/fat/fat.zig) — no kernel knows
 what a key is.
 
 ## One service, several device classes
@@ -43,10 +43,13 @@ consequences decide the whole design:
 
 2. **A synchronous push can hang the whole service.** If the service delivered with
    `ipc_call`, it would block until each subscriber replied. `ipc_call` has no timeout, and
-   the kernel does **not** wake a caller parked on a *dead* peer's endpoint (it only fails a
-   peer that was mid-reply — see [process.zig](../system/kernel/process.zig)
-   `releaseTaskResourcesLocked`). One subscriber that exits mid-delivery would wedge input
-   for everyone. That is the opposite of the resilience the microkernel is for.
+   a subscriber's endpoint is an *unregistered* capability the kernel's death path cannot
+   reach (since display v2's V6, `killOwnedEndpointsLocked` in
+   [ipc-synchronous.zig](../system/kernel/ipc-synchronous.zig) marks a dead owner's
+   *registered* endpoints dead and wakes parked callers with `-EPEER` — but unregistered
+   ones just drop with the task's handle table). One subscriber that exits mid-delivery
+   would wedge input for everyone. That is the opposite of the resilience the microkernel
+   is for.
 
 The fix is the asynchronous send that [ipc.md](ipc.md) had already earmarked as future
 work ("asynchronous / buffered send … for notifications between servers"):