starkernel: land console_fb_init() reorder (FABRIC.md 4.4g decided)

Moves the console_fb_init() call in kernel_main.c from after
capsule_birth_mama() to before it, so the fleet-birth/self-test
transcript (Hermes x2, Artemis births, Stadium self-tests -- currently
serial-only) is also framebuffer-visible, not just the small post-birth
tail.

4.5f's -O2 experiment already showed this doesn't hang under
optimization, just costs roughly 12x more boot-time heartbeat ticks
(one-shot, paid only during fleet birth, never repeated at runtime).
Captain Bob's call: worth it, since the serial log was never the
problem -- this is about the same transcript also reaching a real
screen.

Three-arch verified: amd64/aarch64/riscv64 all reach ok>, POST
Failed: 0, identical dict-hashes across all three. amd64 screendump
confirms the framebuffer now carries the full transcript.

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

FABRIC.md

@@ -5176,7 +5176,7 @@ document and committing that amendment as its own item.*
   > linked from 4.4d/4.4e above. Three-arch serial boot clean, same basis as 4.4c.
   > Screendump verification remains amd64-only, same accepted gap as 4.4c/4.4d/4.4e.
 
-- [ ] **4.4g — Design decision needed: `console_fb_init()` runs after capsule birth, not
+- [x] **4.4g — Design decision needed: `console_fb_init()` runs after capsule birth, not
   before, so almost all boot output is framebuffer-invisible by construction.** Found while
   verifying 4.4c/4.4d by screendump — initially logged as an unexplained rendering anomaly
   (hundreds of lines of `log_message()`-driven HADES/ECW/Stadium/self-test output missing
@@ -5211,6 +5211,20 @@ document and committing that amendment as its own item.*
   > `console_putc()` calls issued after kernel_main.c:852; everything above that line in the
   > serial log predates the framebuffer console's existence.
 
+  > **Decided, 2026-08-11 — yes, reorder.** Captain Bob's reasoning: the serial log already
+  > captures the full transcript losslessly, so this isn't about not losing data; it's about
+  > that same transcript also being visible on a real screen. Weighed against 4.5f's measured
+  > cost (~12x more boot-time heartbeat ticks, roughly 2700–5300 vs ~200 depending on
+  > architecture) — confirmed one-shot, paid only during the fleet-birth/self-test sequence
+  > at boot, never repeated during REPL/runtime — and judged worth it ("that's nothing").
+  > `console_fb_init()`'s call site moved permanently in `kernel_main.c`, from after
+  > `capsule_birth_mama()` to just before it. Three-arch verified: amd64
+  > (`logs/20260811-171007/amd64/`), aarch64 (`logs/20260811-171118/aarch64/`), riscv64
+  > (`logs/20260811-171322/riscv64/`) — all reach `ok>`, POST `Failed: 0`, identical
+  > dict-hashes across all three. Screendump on the landed build:
+  > [evidence/amd64/qemu-screenshot-20260811-171612-4.4g-landed.png](evidence/amd64/qemu-screenshot-20260811-171612-4.4g-landed.png)
+  > — framebuffer now shows the full HADES/ECW/Stadium/self-test transcript, not just the tail.
+
 - [ ] **4.4h — Apply color to the prompt.** Depends on 4.4d (coloring a bracket that isn't
   drawn on screen accomplishes nothing). Per 4.4b's finding: either an independent
   `TTF-TEXT` call with the color from 4.4, or gated on 4.4j completing first.
@@ -5822,7 +5836,7 @@ document and committing that amendment as its own item.*
   > (`0x211a35043331d472` Mama / `0x97502db38aec4d04` Hermes), confirming cross-arch parity
   > holds under `-O2`.
 
-- [ ] **4.5f — Retry the 4.4g `console_fb_init()` reorder now that optimization is live.**
+- [x] **4.5f — Retry the 4.4g `console_fb_init()` reorder now that optimization is live.**
   Depends on 4.5e. This is the original motivating case: both attempts this session (bare,
   and with the `fb_scroll_rows()` volatile fix alone) stalled boot indefinitely at `-O0`.
   *Done when:* the reorder from 4.4g completes in a reasonable time (no multi-minute stall)
@@ -5862,6 +5876,11 @@ document and committing that amendment as its own item.*
   > only removes "it hangs" as a reason not to. The real-cost number above (≈12× more
   > heartbeat ticks) is new information for that decision and wasn't available before this
   > run.
+  >
+  > **4.4g decided "yes," reorder landed for real, 2026-08-11 — see 4.4g's own record for the
+  > full three-arch verification and final screendump.** This item's own done-when (three-arch
+  > boot with no stall, amd64 screendump of the fuller transcript) is now satisfied by that
+  > same landing, not a separate pass.
 
 - [ ] **4.6 — Artemis last.** It works today; it is the thing that cannot be broken.
   *Refs:* §10.