aarch64: virtio-keyboard-pci, interrupt-driven keyboard input (item 4.3.5e)

Punch list §25 item 4.3.5e complete.

Extended virtio_input.c with a GIC-routed interrupt path alongside 4.3.5c's
PLIC one -- same capability walk, feature negotiation, eventq handling
(confirming §27.5.1's prediction that these items would share most of the
driver). aarch64_irq_handler() dispatches to virtio_input_isr() before its
EOIR write, same claim-dispatch-complete ordering riscv64 uses. Verified
with a real QEMU sendkey keypress: exact KEY_A/press match, two real
interrupts serviced, identical result to riscv64. Found (not fixed) an
unrelated pre-existing bug: BYE's cold-reset path faults on aarch64,
discovered incidentally since nobody had exercised it from a monitored
session before. Three-arch acceptance boot clean.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC.md

@@ -4215,7 +4215,7 @@ document and committing that amendment as its own item.*
   > live (`virtio-blk-pci` uses it today on this same board). Probe code reverted after
   > recording this result — not committed; this item remains unstarted.
 
-- [ ] **4.3.5e — aarch64: virtio-keyboard-pci, interrupt-driven.** Add `virtio-keyboard-pci`
+- [x] **4.3.5e — aarch64: virtio-keyboard-pci, interrupt-driven.** Add `virtio-keyboard-pci`
   to the aarch64 `qemu`/`qemu-esp` targets — the existing `virtio-blk-pci` device proves the
   PCI bus is already enumerated (`pci.c`) on this board, so this rides the same bus, a new
   device class. Same virtio-input driver shape as 4.3.5c (shared code where the transport
@@ -4279,6 +4279,50 @@ document and committing that amendment as its own item.*
   unaffected, log committed.
   *Refs:* §27.5.
 
+  > **Done, 2026-08-08.** `virtio_input.c`'s `enable_interrupt_route()` gained an
+  > `#elif defined(ARCH_AARCH64)` branch alongside 4.3.5c's riscv64 one — same slot/pin
+  > read (`PCI_CFG_INT_PIN`), the §27.5.1 formula (`spi = 3 + ((slot+pin-1) % 4)`, INTID =
+  > `32 + spi`) instead of riscv64's §27.5.2 one, calling `apic_spi_enable()` (item 4.3.5d)
+  > instead of `plic_enable()`. New `g_virtio_input_gic_intid` global, same "0 is a safe
+  > sentinel" reasoning as riscv64's `g_virtio_input_plic_source` (SPIs start at INTID 32,
+  > never 0). Everything else in the file — capability walk, feature negotiation, eventq
+  > pre-posting, the mandatory ISR-status read — is unchanged, exactly as §27.5.1's original
+  > amendment predicted ("this item and 4.3.5e now share most of the actual virtio-input
+  > driver logic"). `aarch64_irq_handler()` (`interrupts.c`) dispatches to `virtio_input_isr()`
+  > **before** its `GICC_EOIR` write, same claim-dispatch-complete ordering riscv64 uses —
+  > required here for a real reason: EOI'ing a still-asserted level-triggered line first
+  > would let the GIC immediately re-signal it. `keyboard_words.c`'s `VKBD-EVENT`/`VKBD-DEBUG`
+  > guards extended to `ARCH_AARCH64` (previously riscv64-only) — both words already used
+  > arch-agnostic `virtio_input.c` symbols, so this was a guard change only, no new logic.
+  > `-device virtio-keyboard-pci,addr=0x3` added to the aarch64 `qemu` target (the item's
+  > text also named `qemu-esp`, but that target has no virtio-blk-pci/Artemis disk either —
+  > not part of §25.0's acceptance boot, skipped as a report-not-fix imprecision in the
+  > original item wording, not a deviation from anything load-bearing).
+  >
+  > Verified with a real keypress, same technique as 4.3.5c: temporary monitor socket
+  > (reverted after), QEMU HMP `sendkey a`, `VKBD-EVENT . . . CR VKBD-DEBUG . CR` over the
+  > serial socket. Result: `-1 1 30` (`code=30` = `KEY_A` exactly, `value=1` = press) then
+  > `2` (two real interrupts serviced) — identical to riscv64's result, first try, no
+  > equivalent of 4.3.5d's DAIF bug (this path runs after `arch_enable_interrupts()`, unlike
+  > that item's self-test which deliberately ran before it)
+  > (`logs/20260808-122317/aarch64/qemu-aarch64-20260808-122317-sendkey-verify.log`).
+  >
+  > **Found incidentally, reported not fixed:** after the verification above completed
+  > cleanly, sending `BYE` to the same session produced `*** EXCEPTION (aarch64) ***`
+  > (`ESR_EL1=0x02000000`, EC=0/"unknown reason") in `arch_cold_reset()`'s cold-restart path
+  > — same log, lines after the passing test output. Confirmed unrelated to this item
+  > (`arch.c`'s reset path, nothing this item touched) and confirmed not a regression this
+  > item introduced: riscv64's equivalent `BYE`-terminated session
+  > (`logs/20260808-114907/riscv64/`) shows no exception at the same point. Nobody had
+  > exercised `BYE` from a monitored serial session before either verification run this
+  > session, which is why this surfaced only now. Not this item's job to fix.
+  >
+  > Three-architecture acceptance boot clean (standard `make qemu`, no monitor socket, `BYE`
+  > never sent): amd64 (`logs/20260808-122554/amd64/`), aarch64 (`logs/20260808-122640/
+  > aarch64/`, `virtio-input: found device` / `driver ready` present), riscv64
+  > (`logs/20260808-122743/riscv64/`, unaffected — this item's riscv64-side changes were
+  > doc-comment-only).
+
 - [ ] **4.3.5f — Checkpoint: one keyboard abstraction, three architectures, no polling.**
   Converge 4.3.5/4.3.5c/4.3.5e behind a single scancode/keycode interface so the REPL
   keyboard-input work (M8, outside Stadium) has one thing to call, not three. Stop and