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

@@ -7,19 +7,23 @@ tree** (DTB). This note is a design plan, not built yet: *when* danos should tac
 it, and *how* to keep it architecture-agnostic — the same discipline the
 [memory map](memory-map.md) and [architecture split](architecture.md) already follow.
 
-## What the kernel assumes today
+## What the kernel assumed when this plan was written
 
-Right now danos discovers almost nothing — it coasts on legacy PC fixtures that are
-guaranteed to exist under QEMU + UEFI:
+At the time danos discovered almost nothing — it coasted on legacy PC fixtures that
+are guaranteed to exist under QEMU + UEFI:
 
-- `arch/x86_64/apic.zig` assumes the **Local APIC** at the default `0xFEE0_0000` and
-  calibrates its timer against the **PIT** (the legacy 8254).
-- `arch/x86_64/serial.zig` hardcodes **COM1** at I/O port `0x3F8`.
+- `system/kernel/architecture/x86_64/apic.zig` assumed the **Local APIC** at the
+  default `0xFEE0_0000` and calibrated its timer against the **PIT** (the legacy
+  8254). (Today the PIT is the *last-resort* reference: calibration prefers the
+  CPUID-reported TSC frequency, then the HPET, then the ACPI PM timer.)
+- `system/kernel/architecture/x86_64/serial.zig` hardcoded **COM1** at I/O port
+  `0x3F8`. (Today `0x3F8` is only the default: the kernel loopback-probes the UART
+  and parses ACPI's SPCR table to target the firmware's actual debug port.)
 - The framebuffer and memory map come from **UEFI** — that *is* discovery, just done
   by the firmware and handed over, not read from ACPI.
 
-This works only because PC-compatible hardware promises those legacy pieces exist at
-those addresses. It is a crutch, and it does not travel.
+This worked only because PC-compatible hardware promises those legacy pieces exist at
+those addresses. It was a crutch, and it did not travel.
 
 ## The forcing functions: when to build it
 
@@ -53,8 +57,8 @@ it isn't really agnostic.
 
 ## The one cheap step to take sooner
 
-Have the **loader capture the description pointer** into `BootInfo` — a neutral
-handle, no parsing:
+Have the **loader capture the description pointer** into `BootInformation` — a
+neutral handle, no parsing:
 
 ```zig
 pub const HardwareInfo = extern struct {
@@ -146,7 +150,7 @@ free; discovery on x86 is partly about *finding* what ARM just tells you.
 ## Suggested ordering
 
 1. **Now (cheap):** plumb the neutral `HardwareInfo` pointer through the loader into
-   `BootInfo`. No parser yet.
+   `BootInformation`. No parser yet.
 2. **Next milestone unchanged:** user mode + address-space isolation — needs no
    discovery.
 3. **With the aarch64 port:** build the agnostic discovery layer, **DTB first** (the
@@ -182,15 +186,20 @@ the static tables (MADT, HPET, MCFG, FADT + `\\_S5`) stay kernel-side.
 
 The kernel no longer folds the AML namespace's Device objects into the device
 tree. It still parses the *static* tables (MADT for SMP, HPET for the tick, MCFG
-for the host bridge, FADT) and still builds the AML namespace — but only to read
-the `\\_S5` sleep type for poweroff. Device discovery is the ring-3 **acpi
+for the host bridge, FADT); at this point it also still built the AML namespace —
+but only to read the `\\_S5` sleep type for poweroff. (That remnant is gone too:
+the kernel now runs no AML at all — soft-off belongs to the acpi service, and the
+kernel keeps only the AML-free reboot path.) Device discovery is the ring-3 **acpi
 service** ([device-manager.md](device-manager.md)): it claims the `acpi-tables`
 node the kernel publishes (the AML blobs, a broad io_port grant, the SCI),
 re-parses the same blobs with the shared AML module, evaluates `_STA`/`_CRS`,
 and registers + reports each `_HID` device — the device manager matches drivers
 (ps2-bus) from those reports. With M19's pci-bus driver, discovery now runs
-entirely in user space; the kernel seeds only the host bridge and the
-acpi-tables node.
+entirely in user space, anchored on two kernel-seeded nodes: the host bridge and
+the acpi-tables node. (The kernel's static-table parse also seeds the processor,
+interrupt-controller, and HPET timer nodes, and it publishes the boot
+framebuffer as a claimable display node — but no *enumeration* happens in
+ring 0.)
 
 ## Discovery is a swappable process per firmware (M19–M20)
 
@@ -231,11 +240,14 @@ Two consequences of neutrality bind on later work:
 
 Two supporting decisions keep the kernel's remaining slice honest:
 
-- **The AML interpreter is a shared build module**, compiled into both the
-  kernel and the acpi service — one source, two builds, no fork. The kernel
-  links it for the `\_S5` poweroff evaluation, the service links it for
-  everything else, and the `acpi-parse` test asserts the two produce the same
-  device count across the ring-3 move.
+- **The AML interpreter is a single build module**
+  (`system/devices/aml/aml.zig`) — one source, no fork. During the ring-3 move
+  it was compiled into both the kernel (which linked it just for the `\_S5`
+  poweroff evaluation) and the acpi service, with the `acpi-parse` test
+  asserting the two produce the same device count. Since soft-off followed
+  discovery out of the kernel, only the acpi service links the module — the
+  kernel runs no AML — and the test now asserts a device-count *floor* for the
+  ring-3 parse instead, there being no kernel count left to equal.
 - **Bridge apertures come from the firmware memory map, not AML.** Registered
   PCI functions carry BAR resources, and `device_register` containment demands
   the bridge own windows that cover them. Those apertures are derived