docs: mark interrupts.md 'what's next' items as done (IO-APIC, SSE state)

docs/interrupts.md

@@ -122,14 +122,22 @@ fault** — reported cleanly (`double fault (vector 8)`) rather than triple-faul
 into a reset, which only works because #DF ran on IST1. That's the proof the
 TSS/IST is wired up: the handler survived a completely broken stack.
 
-## What's next (not done here)
+## What's next (since done)
 
-- **The IO-APIC and the keyboard**: the timer (a local-APIC device interrupt) is
-  covered in [device-interrupts.md](device-interrupts.md); external devices like
-  the keyboard also need the IO-APIC to route their lines onto vectors.
-- **SSE state**: the stubs save general registers but not the vector registers, so
-  a returning interrupt whose handler uses SSE will need that added. Fine for now,
-  since our handlers don't.
+Both items originally deferred here have landed:
+
+- **The IO-APIC**: [ioapic.zig](../system/kernel/architecture/x86_64/ioapic.zig)
+  routes external device lines onto vectors — discovered via ACPI's MADT, every
+  input masked at init, lines unmasked one at a time as user-space drivers bind
+  them (see [device-interrupts.md](device-interrupts.md)). The keyboard turned
+  out not to need it: danos's keyboard is USB HID over xHCI, which interrupts via
+  MSI, not an ISA line. The IO-APIC path is still exercised — e.g. by the HPET's
+  GSI routing.
+- **SSE state**: `isr_common` (and the syscall entry) now `fxsave`/`fxrstor` the
+  full SSE/x87 register file around dispatch. This stopped being optional the
+  moment kernel code touched XMM — a 16-byte struct copy is a `movdqu` — and its
+  absence was the root cause of a long-lived corruption Heisenbug; the comments
+  in `isr.s` tell the story.
 
 With faults now debuggable, the paging work that follows — where a wrong
 page-table entry means an instant #PF — is far less painful.