riscv64: explicit Bare-mode satp switch (item 4.3.5a)

Punch list §25 item 4.3.5a complete.

Firmware (EDK2 RISC-V) leaves Sv57 paging active at kernel entry with an
identity mapping that has at least one confirmed hole (PLIC threshold
register). Verified live before acting: satp.MODE/PPN and __kernel_start's
address confirmed identity mapping; switched to Bare mode (csrw satp, x0 +
sfence.vma) in arch_early_init(), ahead of pmm_init()/vmm_init().
Three-arch acceptance boot clean, zero exceptions; riscv64's PLIC_THRESHOLD
write now survives (PLIC driver code itself lands separately with 4.3.5b).

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

FABRIC.md

@@ -3919,7 +3919,7 @@ document and committing that amendment as its own item.*
   > aarch64, `logs/20260808-001637` riscv64) — the feature is amd64-only this item, so
   > aarch64/riscv64 are a regression check, not a keyboard test.
 
-- [ ] **4.3.5a — riscv64: minimal paging/addressing bring-up (prerequisite, blocks
+- [x] **4.3.5a — riscv64: minimal paging/addressing bring-up (prerequisite, blocks
   4.3.5b).** Discovered live 2026-08-08 while implementing 4.3.5b, not anticipated when
   4.3.5a-4.3.5f were originally scoped. **riscv64 has no software-controlled paging at
   all.** `arch/riscv64/arch.c`'s own comment is explicit: "Full Sv39/Sv48 page-table setup
@@ -3947,6 +3947,42 @@ document and committing that amendment as its own item.*
   faulting, three-arch QEMU boot clean, log committed.
   *Refs:* §27.5.
 
+  > **Done, 2026-08-08.** Chose Bare mode over Sv39 bring-up: this kernel builds no riscv64
+  > page table of its own (`vmm.c`'s is x86-64-shaped and never activated here) and has no
+  > present use for virtual memory on this ISA, so there was no reason to build one just to
+  > patch the one confirmed hole. Verified live before touching `satp`, not assumed: added a
+  > read-only diagnostic to `arch_early_init()` (`arch/riscv64/arch.c`, already called at
+  > `kernel_main.c:401`, ahead of both `pmm_init()` and `vmm_init()`) printing `satp`'s
+  > MODE/PPN and `__kernel_start`'s address. Result — `satp.MODE = 0xa`: firmware (EDK2
+  > RISC-V) leaves **Sv57** active at kernel entry, not Sv39/Sv48 as this file's own stub
+  > comment assumed (that comment was stale; corrected in the same edit). `__kernel_start`
+  > (`0xbdd56982`) landed inside the UEFI-reported total physical RAM window
+  > (`0x80000000`–`0x80000000+1020MB`), near the top past the PMM-free region — consistent
+  > with the kernel's own running range being identity-mapped, the load-bearing assumption
+  > for the fix's safety. Fix: `csrw satp, x0` + `sfence.vma` in one `asm volatile` block
+  > (RISC-V Privileged Spec §4.2.1 ordering — must not be separated by a compiler-scheduled
+  > memory access), placed in `arch_early_init()` right after the diagnostic prints, which
+  > are now kept as a permanent boot record rather than reverted.
+  >
+  > Two-boot verification, per §25.0 rule 6 (acceptance is not "should work"): first a
+  > diagnostic-only riscv64 boot confirmed the satp/identity-mapping facts above
+  > (`logs/20260808-101931/riscv64/`, still hits the original `scause=0xF` fault since the
+  > fix wasn't written yet); then, with the fix added, a second riscv64 boot confirmed
+  > `plic_init()`'s `PLIC_THRESHOLD` write at `0x0c201000` now succeeds with zero exceptions
+  > (`logs/20260808-110152/riscv64/`) — this is the already-written, still-uncommitted 4.3.5b
+  > PLIC driver code in the working tree, exercised live but not part of this commit.
+  > Three-architecture acceptance boot clean, zero exceptions on any: amd64
+  > (`logs/20260808-110252/amd64/`), aarch64 (`logs/20260808-110345/aarch64/`), riscv64
+  > (`logs/20260808-110500/riscv64/`, `PLIC: init` line present, no fault).
+  >
+  > **Reported, not fixed (§25.0 rule 3):** `arch_mmu_init()` is declared and defined on all
+  > three architectures but `kernel_main.c` never calls it anywhere — dead code tree-wide,
+  > pre-existing, unrelated to today's fix (which lives in `arch_early_init()` instead,
+  > specifically to avoid routing a riscv64-only change through a shared call site that would
+  > newly execute on amd64/aarch64 too). Also: the uncommitted 4.3.5b driver code's own
+  > 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
   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
@@ -4110,6 +4146,22 @@ document and committing that amendment as its own item.*
   > rendering nor REPL has *Done when* criteria yet. Per §25.0 rule 2, each gets scoped in
   > detail at its own checkpoint, not now.
 
+  > **Landing point noted 2026-08-08, not yet scoped:** whatever 4.3.5f's shared interface
+  > produces has to eventually feed the FORTH-79 terminal I/O words, not just sit behind a
+  > new kernel API nothing calls. Checked, not assumed: `KEY`/`?TERMINAL`/`EMIT`/`EXPECT`
+  > are already registered (`src/word_source/io_words.c:247-250`, `string_words.c:994`) —
+  > this is the shared/vendored VM source, same words the hosted build has. In the kernel
+  > build both are dead today: `io_word_key()` calls libc `getchar()`, which
+  > `src/starkernel/vm/host/shim.c:1206` hardcodes to always return `-1` (EOF); `?TERMINAL`
+  > (`io_words.c:100-108`) is its own literal stub — "Simple implementation - always return
+  > false for now." So there is currently no keyboard path into the VM on any architecture,
+  > confirmed by reading the code, not inferred from the milestone status. `EMIT`/`putchar()`
+  > already routes to `console_putc()` (`shim.c:1100`) — only the input side is stubbed.
+  > Not scoped now, per §25.0 rule 2 — recorded so it isn't lost before REPL wiring is
+  > scoped. Whether the fix lands in `shim.c`'s `getchar()`, in `io_words.c` under
+  > `#ifdef __STARKERNEL__`, or elsewhere is an open question for that later item, not
+  > decided here.
+
   ⋯ *(4.3.x is open-ended — more items get appended here as Console work is scoped item by*
   *item, developed on the fly per §25.0. 4.4 below is unaffected by anything added above*
   *this marker.)*