FABRIC.md: 4.4b -- prompt color does not depend on the TTF retarget

Punch list §25 item 4.4b complete.
Investigation only, no code. draw_cursor_glyph() (vt100.c:125) already
draws through g_vt.fg/g_vt.bg via fb_draw_glyph(), and apply_sgr() already
parses true 24-bit-color SGR (ESC[38;2;R;G;Bm) -- color reaches the screen
today independent of which font renders the glyph. 4.4c can proceed without
waiting on 4.4d/4.4e.

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

FABRIC.md

@@ -5041,7 +5041,7 @@ document and committing that amendment as its own item.*
   > amd64 (`logs/20260811-073408/`), aarch64 (`logs/20260811-073448/`), riscv64
   > (`logs/20260811-073542/`).
 
-- [ ] **4.4b — Resolve: does prompt color depend on 4.4e?** Investigation, not implementation.
+- [x] **4.4b — Resolve: does prompt color depend on 4.4e?** Investigation, not implementation.
   Read the REPL's actual output path (`console_puts()` → ... → `vt100_putc()` →
   `draw_cursor_glyph()`, all currently `font_8x16.c`) to determine whether a single
   hardcoded-color prompt segment can call `TTF-TEXT` directly, independent of the general
@@ -5052,6 +5052,19 @@ document and committing that amendment as its own item.*
   actual call chain, not assumed.
   *Refs:* §27.8.
 
+  > **DONE 2026-08-11 — answer: no dependency on 4.4e.** `draw_cursor_glyph()`
+  > (`vt100.c:125`) already calls `fb_draw_glyph(px, py, ch, f, b)` with `f`/`b` taken from
+  > `g_vt.fg`/`g_vt.bg` — color support is already wired all the way through the *existing*
+  > `font_8x16.c` pipeline, completely independent of which font renders the glyph shape.
+  > `apply_sgr()` (`vt100.c:337-348`) already parses true 24-bit-color SGR:
+  > `ESC[38;2;R;G;Bm` sets foreground RGB directly (not limited to the 16/256-color palette),
+  > `ESC[39m` resets to default. So 4.4c does not need to wait on 4.4e/4.4d at all — it can
+  > send `ESC[38;2;255;165;0m` (4.4's locked orange) before the bracket, `ESC[39m` after, and
+  > `ESC[38;2;85;255;255m` (4.4's locked cyan) before `ok> `, all through `console_puts()`
+  > exactly as it works today. TTF (4.4d/4.4e) changes *what draws the glyph*, not *whether
+  > color reaches the screen* — those are orthogonal, confirmed by reading the call chain
+  > rather than assumed.
+
 - [ ] **4.4c — Apply color to the prompt.** Per 4.4b's finding: either an independent
   `TTF-TEXT` call with the color from 4.4, or gated on 4.4e completing first.
   *Done when:* three-arch screendump shows `[VM name]` and `ok>` in the colors locked at 4.4;