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/memory-map.md

@@ -57,22 +57,27 @@ itself, `@sizeOf` is authoritative: the kernel walks a plain `[]MemoryRegion` wi
 no variable-stride subtlety (that stride problem is a UEFI-ism, and it stays in the
 loader).
 
-`BootInfo` carries it alongside the framebuffer:
+`BootInformation` carries it alongside the framebuffer (trimmed here to the
+fields this page is about — the full struct has since grown the kernel's
+PT_LOAD segments, the ACPI RSDP, and the initial-ramdisk span):
 
 ```zig
-pub const BootInfo = extern struct {
+pub const BootInformation = extern struct {
     framebuffer: Framebuffer,
     memory_map: MemoryMap,
+    // ...kernel_segments, acpi_rsdp, initial_ramdisk_base/len
 };
 ```
 
 ## The loader side (UEFI)
 
-Two functions in `boot/efi.zig`, called from `exitBootServices`:
+Two functions in `boot/efi.zig`: `exitBootServices` calls `convertMemoryMap`,
+which runs `classify` on each descriptor:
 
 - **`classify`** maps each UEFI descriptor to a `MemoryKind`:
   `conventional_memory` **and** `boot_services_code`/`boot_services_data → usable`;
-  `acpi_reclaim_memory → acpi_tables`; `acpi_memory_nvs → acpi_nvs`; **everything
+  `acpi_reclaim_memory → acpi_tables`; `acpi_memory_nvs → acpi_nvs`;
+  `memory_mapped_io`/`memory_mapped_io_port_space → mmio`; **everything
   else → reserved** (the safe default). Our own `loader_data` — the kernel image and
   these buffers — falls into `reserved`.
 
@@ -120,18 +125,25 @@ for the conversion.)
 The kernel receives a plain array and reads it with zero UEFI knowledge:
 
 ```zig
-const mm = boot_info.memory_map;
-const regions = @as([*]const system.MemoryRegion, @ptrFromInt(mm.regions))[0..mm.len];
+const mm = boot_information.memory_map;
+const regions = @as(
+    [*]const boot_handoff.MemoryRegion,
+    @ptrFromInt(boot_handoff.physicalToVirtual(mm.regions)),
+)[0..mm.len];
 for (regions) |r| {
     if (r.kind == .usable) usable_pages += r.pages;
 }
 ```
 
+(`mm.regions` is a physical address, so it's dereferenced through the physmap —
+`physicalToVirtual` — since the kernel no longer runs under the loader's
+identity map.)
+
 `kmain` summarises the map to prove the handoff works. Booted in QEMU with
 128 MiB, it reports:
 
 ```
-danos: physical memory
+/system/kernel: physical memory
   total RAM  : 0.12 GiB (127 MiB) - RAM the firmware reported
   usable     : 121 MiB - free RAM (incl. reclaimed boot-services memory)
   reserved   : 6 MiB - kernel image, boot stack, ACPI, runtime services