riscv64: PLIC bring-up, external-interrupt substrate (item 4.3.5b)

Punch list §25 item 4.3.5b complete.

sie.SEIE enabled, PLIC threshold/claim/complete wired into the trap
handler. Verified with a UART-loopback synthetic interrupt (PLIC has no
software set-pending register, unlike GICv2): claim_count=1, last_irq=10,
IIR confirms genuine receive-data cause, byte matched exactly. Self-test
code run once for evidence then fully reverted, per Captain Bob's ruling;
only the permanent substrate remains, no source enabled by default.
Three-arch acceptance boot clean, zero exceptions.

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

FABRIC.md

@@ -3983,7 +3983,7 @@ document and committing that amendment as its own item.*
   > comments still label itself "item 4.3.5a" — stale from before this item was inserted
   > ahead of it; needs a rename to "4.3.5b" before that commit lands, not this one's job.
 
-- [ ] **4.3.5b — riscv64: PLIC bring-up (external interrupt controller).** Does not exist
+- [x] **4.3.5b — riscv64: PLIC bring-up (external interrupt controller).** Does not exist
   anywhere in this tree — Phase 0 (0.2/0.3) only ever enabled the S-mode *timer* interrupt
   (`sie.STIE`); external interrupts (`sie.SEIE`, bit 9) were never touched, and
   `interrupts.c`'s own comment ("the PLIC replaces both") describes the architecture, not
@@ -3996,6 +3996,37 @@ document and committing that amendment as its own item.*
   through the PLIC on riscv64, three-arch QEMU boot unaffected, log committed.
   *Refs:* §27.5.
 
+  > **Done, 2026-08-08.** Unblocked by 4.3.5a. The driver code itself (`plic.c`/`plic.h`,
+  > `apic.c`/`interrupts.c` wiring) predates this item's own insertion point in the sequence
+  > — its comments still said "item 4.3.5a"; corrected to "4.3.5b" (and the two
+  > forward-references to "a future consumer, 4.3.5b" corrected to "4.3.5c", since 4.3.5b is
+  > this item, not the consumer) as part of this commit. PLIC itself has no software
+  > set-pending register (SiFive PLIC-1.0.0, unlike GICv2's `ISPENDR` — pending bits are
+  > hardware-line-driven only), so "synthetic/known" here meant a real, already-present
+  > hardware source: the board's UART (PLIC source 10, per `plic.c`'s own DTB-verified header
+  > comment), driven through its standard NS16550 loopback mode (`UART_MCR_LOOP`, register
+  > offsets/bits confirmed against this build host's `/usr/include/linux/serial_reg.h`, not
+  > recalled) so TX loops back to RX internally — self-contained, deterministic, no external
+  > host-side synchronization, and no race against `repl.c`'s later `console_getc()` polling
+  > since the whole test ran and fully restored UART state before
+  > `arch_enable_interrupts()`'s one real, permanent enable (`kernel_main.c:664`).
+  >
+  > Verified live, not assumed: pre-test `MCR` read back as `0x03`, not `0` — confirms
+  > reading and restoring actual state mattered rather than assuming firmware left it clear.
+  > Result: `claim_count=1`, `last_irq=0xa` (10, the UART), `iir=0xc4` (masks to `0x04` —
+  > `UART_IIR_RDI`, confirming the genuine cause was receive-data, not a fluke or a different
+  > source), `byte=0x55` (exact match to the byte written) — PASS
+  > (`logs/20260808-111711/riscv64/`). Per Captain Bob's ruling 2026-08-08, the self-test
+  > itself (the loopback toggle, the temporary `g_plic_last_irq`/IIR/byte-capture globals,
+  > and its call site in `apic_init()`) was written, run once to capture this evidence, then
+  > fully reverted — same treatment as the aarch64 `GICD_ITARGETSR` probe (item 4.3.5d's
+  > note). Only the permanent substrate remains: `plic_init()` (threshold=0, `sie.SEIE`
+  > enabled, no source enabled — `apic.c`'s own comment already stated that boundary) and the
+  > standing `g_plic_claim_count` diagnostic that predates this item. Three-architecture
+  > acceptance boot clean, zero exceptions on any, in this final reverted state: amd64
+  > (`logs/20260808-112015/amd64/`), aarch64 (`logs/20260808-112108/aarch64/`), riscv64
+  > (`logs/20260808-112235/riscv64/`, `PLIC: init` line present, no fault).
+
 - [ ] **4.3.5c — riscv64: virtio-keyboard-device, interrupt-driven.** Add
   `virtio-keyboard-device` (MMIO virtio, matching the existing MMIO virtio-blk pattern on
   this board) to the riscv64 `qemu`/`qemu-esp` targets in `Makefile.starkernel`. New driver