docs: audit all 'what's next' sections against the code; fix stale comments

Verified every deferred item in the nine docs with a what's-next section and
marked what has since landed (reaper, per-process CR3, higher-half kernel,
kernel heap, contiguous frame alloc, RSDP capture, cap-passing, driver restart
with backoff, PS/2 keyboard) while keeping the genuinely open items. Also
corrects interrupts.md's claim that the keyboard skipped the IO-APIC, and
updates scheduler.zig/heap.zig comments that predated the reaper and the big
kernel lock.

docs/frame-allocator.md

@@ -114,11 +114,13 @@ leaves the single region containing it `reserved`, so `init` won't hand it out.
 later step will move task 0 onto a kernel-owned stack, freeing that last ~1 MiB
 region too (and giving user mode the clean stack it wants).
 
-## What's next (not done here)
+## What's next (partly done since)
 
-- **Contiguous allocation** — scan for N consecutive free bits — for callers that
-  need physically adjacent frames.
-- **A kernel stack for task 0**, so the boot stack's region can be freed too (and
-  for the clean stack user mode wants).
-- **Freeing the `reserved` `loader_data`** (the boot-time map buffers) once the
-  kernel is done reading the memory map.
+- **Contiguous allocation** — done: `allocContiguous` scans for a run of clear
+  bits, with an optional physical ceiling for DMA (`dma_alloc` is its user), and
+  `allocBelow` serves the SMP trampoline.
+- **A kernel stack for task 0** — still open: the boot processor's idle task runs
+  on the boot stack to this day, so that region can't be freed.
+- **Freeing the `reserved` `loader_data`** (the boot-time map buffers) — still
+  open: the bitmap deliberately tracks those frames so they *can* be freed, but
+  nothing frees them yet.