FABRIC.md item 4.4ac: screendump-verify boot scrollback on aarch64/riscv64 too

Extends the amd64 headless screendump verification (99999 SCROLL-BACK
injected over the serial chardev socket, captured via QEMU's HMP
screendump over its monitor socket) to aarch64 (-device ramfb) and
riscv64 (-device ramfb) -- same script shape, no GUI or physical
typing needed on either. Both show the same deep-POST recovery
(Init: Mama birth..., HADES DoE rows 58-73, boot banner) and the same
pre-existing 4.4q live-cursor-draw glitch already confirmed on amd64,
present identically -- boot-mode scrollback is real and reachable on
every architecture, not just amd64.

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

FABRIC.md

@@ -6159,21 +6159,24 @@ document and committing that amendment as its own item.*
 
   > **DONE 2026-08-12.** Three-arch QEMU boot + logs clean, no regression:
   > `logs/20260812-173850/amd64`, `logs/20260812-174418/aarch64`, `logs/20260812-175223/riscv64`.
-  > Screendump verification (`logs/screendump-4.4ac/amd64-scrollback.png`,
-  > `logs/screendump-4.4ac/qemu-amd64.log`) turned out not to need a physical GTK
-  > session as this item originally assumed -- `SCROLL-BACK` is a plain FORTH word, and
-  > `sk_repl_step()`'s input comes from `console_getc()` polling the UART, the same serial
-  > path the old `DOE_INJECT` automation used to drive `EXEC-DOE`. So `99999 SCROLL-BACK`
-  > (clamped to full history) was injected over the serial chardev socket headlessly, then
-  > captured with QEMU's own HMP `screendump` command over its monitor socket -- no GUI, no
-  > physical typing required. The result shows `PARITY:MAMA_INIT`, `Init: Mama birth OK`,
-  > `ACL: CAPSULE-BIRTH pinned STRICT`, `Starting heartbeat...`, and HADES DoE rows from
-  > steps 58-73 all on screen at once -- genuinely early POST content, not the pre-TTF tail,
-  > confirming the boot ring is real and reachable. **Found, not fixed (pre-existing 4.4q
-  > limitation, not introduced here):** the injected serial text got drawn at the live
-  > cursor position even while scrolled back, visibly corrupting two lines
-  > (`okDES][WARN ]`, `ok>  S][DOE ]`) -- exactly the "drawing new live output while
-  > `g_scroll_offset > 0` is unverified... would visually corrupt a scrolled-back view"
+  > Screendump verification, all three architectures (`logs/screendump-4.4ac/*-scrollback.png`,
+  > `logs/screendump-4.4ac/qemu-{amd64,aarch64,riscv64}.log`), turned out not to need a
+  > physical GTK session as this item originally assumed -- `SCROLL-BACK` is a plain FORTH
+  > word, and `sk_repl_step()`'s input comes from `console_getc()` polling the UART, the same
+  > serial path the old `DOE_INJECT` automation used to drive `EXEC-DOE`. So `99999
+  > SCROLL-BACK` (clamped to full history) was injected over the serial chardev socket
+  > headlessly on each arch, then captured with QEMU's own HMP `screendump` command over its
+  > monitor socket -- no GUI, no physical typing required, and the same script shape worked
+  > unmodified across amd64 (`-vga std`), aarch64 (`-device ramfb`), and riscv64 (`-device
+  > ramfb`). All three results show `PARITY:MAMA_INIT`/`Init: Mama birth OK` (amd64) or `Init:
+  > Mama birth...` (aarch64/riscv64), plus HADES DoE rows from steps 58-73, all on screen at
+  > once -- genuinely early POST content, not the pre-TTF tail, confirming the boot ring is
+  > real and reachable on every architecture, not just amd64. **Found, not fixed (pre-existing
+  > 4.4q limitation, not introduced here, present identically on all three arches):** the
+  > injected serial text got drawn at the live cursor position even while scrolled back,
+  > visibly corrupting two lines (`okDES][WARN ]`, `ok>  S][DOE ]`) -- exactly the "drawing
+  > new live output while `g_scroll_offset > 0` is unverified... would visually corrupt a
+  > scrolled-back view"
   > case 4.4q's own comment block already calls out as known and out of scope.
 
 - [ ] **4.5 — URGENT, flagged by Captain Bob 2026-08-11: the kernel build has never used any