docs: record expect-to-python harness migration and 2026-07-20 runtime-proof status

IRQ plan + validation matrix: the login-based QEMU proofs (PS/2 + serio,
monotonic timer, IOMMU first-use, USB storage BOT) now run through
local/scripts/qemu-login-expect.py (stdlib python) instead of the host expect
tool. MSI-X (virtio-net) and xHCI interrupt-driven mode were re-confirmed on
the current redbear-mini ISO. Re-confirmation of the login-based legs with the
new harness is pending an uncontended host (parallel QEMU workload kills QEMU
processes and stalls guest boots). Also record the fbcond Performing-handoff
boot freeze observed with -vga std (separate graphics-path issue).

local/docs/HARDWARE-VALIDATION-MATRIX.md

@@ -31,3 +31,20 @@
 | x2APIC/SMP | ✅ | ✅ | Multi-core works |
 
 ✅ = validated  🔲 = implemented, not validated  N/A = not applicable
+
+### Status note (2026-07-20)
+
+- The login-based QEMU proofs (PS/2 + serio, monotonic timer, IOMMU first-use, USB storage BOT)
+  now run through `local/scripts/qemu-login-expect.py` (stdlib python) instead of the host
+  `expect` tool — no external dependency, per-step timeouts, and safe retry on premature QEMU
+  death. See `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` § "Runtime proof
+  status (2026-07-20)".
+- MSI-X (virtio-net) and xHCI interrupt-driven mode were re-confirmed on the current
+  `redbear-mini` ISO. Re-confirmation of the login-based legs (PS/2, timer, BOT) with the new
+  harness is pending an uncontended host — the current build host runs a parallel QEMU-testing
+  workload that kills QEMU processes and stalls guest boots under load; boots reach getty but the
+  login prompt is not observed within the timeout there. The ✅ marks above reflect prior
+  validation of those legs.
+- Display boots (`-vga std`) can freeze at the fbcond `Performing handoff` step (the
+  `reopen_for_handoff()` path can block rather than return `EAGAIN` for retry). Headless
+  (`-vga none`) boots avoid it. Tracked separately on the graphics stack.

local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md

@@ -176,6 +176,31 @@ The weakest layers are:
 - That is enough to justify further implementation work and proof tooling.
 - It is **not** enough to justify broad hardware robustness claims for PCI/IRQ handling.
 
+### Runtime proof status (2026-07-20)
+
+- MSI-X (virtio-net) and xHCI interrupt-driven mode were **re-confirmed** on the current
+  `redbear-mini` ISO via the log-grep legs (`test-msix-qemu.sh`, `test-xhci-irq-qemu.sh --check`).
+- The login-based proofs (PS/2 + serio, monotonic timer, IOMMU first-use, USB storage BOT)
+  were **migrated off the host `expect` tool** to `local/scripts/qemu-login-expect.py`, a
+  standard-library-only python driver (subprocess + select) that walks ordered `expect:`/`send:`
+  steps over the guest serial console, applies per-step timeouts (matching expect's per-pattern
+  semantics), checks pass/fail markers, and distinguishes premature QEMU death (exit 3) from a
+  genuine check failure (exit 1) so the scripts retry external interruptions without retrying real
+  failures. The four scripts (`test-ps2-qemu.sh`, `test-timer-qemu.sh`, `test-iommu-qemu.sh`,
+  `test-usb-storage-qemu.sh`) now run headless (`-display none -vga none`, using the fbcond serial
+  mirror) with a 3600s per-step timeout and a bounded retry loop.
+- Re-confirmation of those login-based legs with the new harness is **pending an uncontended
+  host**: on the current build host a parallel QEMU-testing workload repeatedly kills QEMU
+  processes and drives multi-minute boot stalls (guest time dilation, full swap). Boots reach the
+  getty stage, but the login prompt is not observed within the timeout under that load. The
+  harness behavior is correct — it waits for `login:` exactly as the prior expect scripts did —
+  and the underlying proofs were previously validated (see the validation matrix).
+- **New finding (graphics path, not low-level controller):** with a display device present
+  (`-vga std`), the fbcond display handoff can freeze the boot at `Performing handoff` — the
+  `reopen_for_handoff()` path (inputd `v2/` scheme proxy / vesad) can block instead of returning
+  `EAGAIN` for the intended retry. Headless (`-vga none`) boots do not take that path and are
+  unaffected. Tracked as a separate desktop/graphics-stack issue.
+
 ## Current Authority Split
 
 For PCI/IRQ planning and current-state language, use the repo doc set this way: