FABRIC.md item 4.4ac: scrollback during boot/POST, not just from REPL

vt100.c: font_8x16/bitmap-mode boot output previously had no scrollback
at all -- g_shadow/g_ring were only allocated in vt100_enable_ttf(), so
POST/self-test/heartbeat text was gone the instant it scrolled off,
recoverable only from the serial log. Gives boot mode its own ring/
shadow pair (bitmap cell geometry, 4096-line capacity), frozen as a
snapshot the moment vt100_enable_ttf() switches to the TTF-geometry
pair, per the two-independent-rings design scoped with Captain Bob.
scrollback_line_at()/scrollback_redraw()/vt100_scroll_back() now walk
all four segments (boot ring, boot shadow, TTF ring, TTF shadow) as one
continuous history, so PgUp from the REPL reaches back through POST.

Three-arch QEMU boot + logs clean (amd64/aarch64/riscv64, no faults, no
dictionary/parity regressions). Visual verification that PgUp actually
recalls POST text still needs an interactive GTK screendump -- noted as
open in FABRIC.md, same pattern as 4.4ab's screendump.

Also includes BLOCK_MAP.md/artemis.img regenerated by these builds, and
the acceptance-boot logs (plus stray logs from an earlier QEMU-instance
collision during testing -- kept per repo convention, logs are audit
artifacts, not deleted).

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

FABRIC.md

@@ -6114,6 +6114,56 @@ document and committing that amendment as its own item.*
   > `: MARGIN 30 SPACES CR ;`, both echoed correctly including shift-key punctuation) —
   > confirms full-width text with no box confinement, no strip, no border artifacts.
 
+- [ ] **4.4ac — Scrollback during boot/POST, not just from the REPL onward.** Scoped
+  2026-08-12, in conversation with Captain Bob. Found while investigating a separate report
+  ("the framebuffer does not mimic the serial port"): `console_putc()` does mirror every byte
+  to both serial and framebuffer during boot, so that report wasn't a mirroring bug — it's
+  that 4.4q's scrollback buffers (`g_shadow`/`g_ring`, `vt100.c:146-150`) are only allocated
+  inside `vt100_enable_ttf()`, sized for the TTF cell grid. Boot/POST runs entirely in
+  `VT_GLYPH_BITMAP` mode against `font_8x16.c`'s fixed 8×16 grid, before that allocation ever
+  happens, so nothing typed to the framebuffer during boot is recoverable once it scrolls off
+  — only the serial log retains it.
+  **Confirmed while scoping: the write path is already mode-agnostic.** `draw_cursor_glyph()`
+  (`vt100.c:278`) and `scroll_up()` (`vt100.c:589`) both gate purely on
+  `g_shadow`/`g_ring != NULL`, with no dependency on which glyph renderer is active. This is
+  not a second recording mechanism to build — it's making the existing one exist earlier.
+  **Decisions locked with Captain Bob 2026-08-12:**
+  1. **Two independent ring buffers**, not a reflow-into-one. A boot-geometry ring/shadow
+     (8×16 cell stride, allocated in `vt100_init()`, `vt100.c:374`) sits alongside the
+     existing TTF-geometry ring/shadow (unchanged, still allocated in `vt100_enable_ttf()`).
+     Avoids re-wrapping stored boot lines to a different column width at the TTF transition,
+     and leaves the already-working TTF scrollback code untouched.
+  2. **Boot ring capacity: 4096 lines (guessed, not measured against a target).** Reasoning:
+     tonight's own qemu-esp serial log ran to ~8,500 lines of POST/Hermes-Artemis-self-test/
+     heartbeat output — 1000 lines (4.4q's current `VT100_SCROLLBACK_MAX_LINES`) would only
+     retain the last ~12% of that. 4096 is a 4x bump, cheap in kmalloc terms (at a typical
+     boot grid this is on the order of 100-200KB), and covers roughly half of tonight's
+     transcript on its own — closing the rest of the gap is expected to come from trimming
+     the actual POST/heartbeat verbosity (a separate, still-open report from the same
+     conversation), not from growing the buffer indefinitely. Revisit this number once that
+     verbosity work happens or is explicitly declined.
+  3. **One continuous scroll across the boot→REPL seam**, not two separately-triggered
+     histories. `scrollback_line_at()` (`vt100.c:465`) needs to walk boot-ring →
+     boot-shadow → TTF-ring → TTF-shadow, in that order, as one combined index space, so
+     PgUp/scroll-back from the live REPL eventually reaches all the way back through POST
+     without a separate command to switch buffers.
+  **Not decided here, deferred to implementation:** exact kmalloc call sites/error handling
+  for the new boot-mode buffers (mirror 4.4q's existing non-fatal-failure pattern at
+  `vt100.c:444-447`); how `scrollback_redraw()` (`vt100.c:480`) picks which stride/cell size
+  to redraw boot-ring lines at once TTF mode has taken over the screen (likely: redraw at
+  *current* mode's cell size regardless of origin, same "text recovers exactly, appearance
+  doesn't" limitation 4.4q already documents for color).
+  *Done when:* three-arch QEMU boot + logs clean; amd64 screendump after scrolling back from
+  a live REPL session shows POST/self-test text recovered, not just the pre-TTF tail.
+  *Refs:* §27.8, 4.4q.
+
+  > **Boot/logs half DONE 2026-08-12; screendump half still open.** Three-arch QEMU boot +
+  > logs clean, no regression: `logs/20260812-173850/amd64`, `logs/20260812-174418/aarch64`,
+  > `logs/20260812-175223/riscv64`. Not yet verified: an actual amd64 screendump showing
+  > recalled POST/self-test text via PgUp scrollback -- that needs a live GTK QEMU window and
+  > someone typing the scroll-back command interactively, the same way 4.4ab's screendump was
+  > captured directly by Captain Bob, not something doable from a headless acceptance boot.
+
 - [ ] **4.5 — URGENT, flagged by Captain Bob 2026-08-11: the kernel build has never used any
   compiler optimization.** **Blocking priority, set by Captain Bob 2026-08-11: no other
   punch-list item is worked until 4.5a–4.5f are done**, ahead of whatever would otherwise