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/danos-file-system-hierarchy-FSH.md

@@ -1,6 +1,6 @@
 # DanOS Filesystem Hierarchy Standard (DFHS)
 
-Most modern Unix and Unix-like operating systems follow the FHS. DanOS has its own FHS structure which extends the unix FHS. This is provided by virtual file system driver (VFS).
+Most modern Unix and Unix-like operating systems follow the FHS. DanOS has its own FHS structure which extends the unix FHS. Root path resolution is provided by the kernel-resident VFS root (`fs_resolve`, `system/kernel/vfs.zig`); mounted filesystem servers serve the subtrees they own.
 
 ## Directory structure
 
@@ -18,7 +18,7 @@ Most modern Unix and Unix-like operating systems follow the FHS. DanOS has its o
 | /system          | DanOS operating system files (similar idea to C:\Windows). A true representation of danos — its layout mirrors the source tree, so `/system` is what danos *is*.    |
 | /system/devices  | danos virtual device tree e.g. similar to /sys on linux but with danos device tree conventions (the structures in the devices module)                               |
 | /system/drivers  | driver binaries, one sub-project each (e.g. /system/drivers/pci-bus, /system/drivers/ps2-bus)                                                                       |
-| /system/services | system-service binaries — the VFS server, init, and other user-mode servers (e.g. /system/services/vfs, /system/services/init)                                      |
+| /system/services | system-service binaries — init, the FAT server, and other user-mode servers (e.g. /system/services/init, /system/services/fat)                                      |
 | /system/kernel   | the kernel image                                                                                                                                                    |
 | /tmp             | Directory for temporary files (see also /var/tmp). Often not preserved between system reboots and may be severely size-restricted.                                  |
 | /usr             | Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications. Should be shareable and read-only.                   |
@@ -48,10 +48,13 @@ willing to serve them, addressed by name.
 
 A device node is not a file the VFS can read. The bytes live in a driver process
 ([drivers.md](drivers.md)), so opening a `/dev` name has to resolve to that driver's
-IPC endpoint, and subsequent reads and writes are calls against it. This is what
-`system/services/vfs/vfs.zig` reserves for M10 and what the `Stat.kind` field is for; **none of it is
-implemented today.** The current VFS is a flat, in-memory ramfs of eight nodes, with no
-directories at all and `kind` hardcoded to zero. The three sections below describe the
+IPC endpoint, and subsequent reads and writes are calls against it. Resolve-to-endpoint
+is exactly what the kernel's `fs_resolve` already does for any mounted backend, and
+`FileStatus.kind` is the field that marks a device node; **what is not implemented today
+is `/dev` itself** — no service mounts it. (The flat eight-node ramfs this section once
+described is retired: the kernel-resident VFS root in `system/kernel/vfs.zig` serves the
+read-only `/system` initrd mount with real directories and node kinds, and filesystem
+backends such as the FAT server mount the rest.) The three sections below describe the
 intended shape, and are honest about which parts the kernel can already support.
 
 ### Character devices
@@ -107,12 +110,13 @@ yielding unpredictable bytes.
 
 These are the only `/dev` entries danos can implement immediately, and they are the
 sensible place to start, because they are exactly the entries that need no driver
-process, no `device_claim`, no MMIO grant and no interrupt. The VFS server answers them
-out of its own address space — `null` and `zero` are a few lines each in
-`system/services/vfs/vfs.zig`'s `read` and `write` handlers. Doing so forces the two pieces of
-structure that every later device node depends on and that the flat ramfs currently
-lacks: a directory, so that `/dev/null` is a path rather than a name; and a populated
-`Stat.kind`, so that a caller can tell a character device from a regular file.
+process, no `device_claim`, no MMIO grant and no interrupt. A future pseudo-device
+service would answer them out of its own address space — `null` and `zero` are a few
+lines each in its `read` and `write` handlers — and mount itself at `/dev` the way the
+FAT server mounts `/mnt/usb`. The two pieces of structure every later device node
+depends on (and that the flat ramfs of the time lacked) exist now: directories, so that
+`/dev/null` is a path rather than a name; and a populated `FileStatus.kind`, so that a
+caller can tell a character device from a regular file.
 
 `/dev/random` is the one that is not free. It needs an entropy source, and the honest
 options on this kernel are `RDRAND`/`RDSEED` where CPUID advertises them, and the HPET