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

@@ -158,11 +158,13 @@ never knows the difference.
 This page is plumbing plus classification only. The map's first consumer, the
 **physical frame allocator**, is built directly on the `usable` regions here — which
 already include the reclaimed boot-services memory the loader folded in (see
-[frame-allocator.md](frame-allocator.md)). Still to come:
+[frame-allocator.md](frame-allocator.md)). Of the two items once listed here, one is done:
 
-- Freeing the `reserved` `loader_data` (these boot-time buffers) once the kernel is
-  done reading the map.
+- Freeing the `reserved` `loader_data` (these boot-time buffers) once the kernel
+  is done reading the map — still open: the frame allocator's bitmap tracks those
+  frames so they can be freed, but nothing frees them yet.
 - Capturing the ACPI RSDP from the UEFI configuration table before exit (the same
-  "grab it before ExitBootServices" pattern), for when ACPI parsing arrives.
+  "grab it before ExitBootServices" pattern) — done: the loader stows it in the
+  boot handoff, and ACPI parsing consumes it from there ([acpi.md](acpi.md)).
 
 See the roadmap in [efi.md](efi.md) for where this sits in the boot flow.