starkernel: item 4.3.1 -- framebuffer orientation test, found and fixed a real color-swap bug

Adds fb_draw_orientation_test() (framebuffer.c/.h): fills the four raster
corners RED/GREEN/BLUE/YELLOW via fb_fill_rect. Wired into kernel_main.c
calling fb_init() directly -- console_fb_init()/vt100_init() removed from
the boot path, since vt100.c/console.c are superseded by the Console
drawing-fabric redesign (FABRIC.md ss27) and should not be exercised even
incidentally.

The diagnostic caught a real, pre-existing bug on its first run: framebuffer.c's
pack_pixel() had its FB_PIXEL_RGBX32/FB_PIXEL_BGRX32 branches swapped relative
to UEFI GOP's own byte-order naming convention, producing a clean R<->B channel
swap (G unaffected). Spatial placement was already correct -- no flip/rotation.
Fixed by swapping pack_pixel's two return bodies to match framebuffer.h's
already-correct doc comments; kernel_main.c's GOP-format switch needed no change.

Also item 4.3.2 -- QEMU screenshot capability. scripts/qemu_screenshot.sh
already existed (monitor socket + socat + HMP screendump), just unwired and
unused this session. Redirected its PNG output to a new top-level fb/
directory (tracked in git, not logs/, not a gitignored temp dir) and added a
python3+PIL fallback for PPM->PNG conversion since imagemagick isn't
installed here. Left as a standalone script for now, not wired into a
Makefile target.

FABRIC.md items 4.3.1 and 4.3.2 marked done with acceptance evidence.

FABRIC.md

@@ -3652,15 +3652,46 @@ document and committing that amendment as its own item.*
   > scrolling, cursor/VT100 semantics, the Hermes message protocol, and Console as a fleet
   > VM under Hera's birth protocol — later 4.3.x items, scoped once this slice is reviewed.
 
-- [ ] **4.3.1 — Framebuffer sanity: draw a test pattern.** Confirm `framebuffer.c` is wired
+- [x] **4.3.1 — Framebuffer sanity: draw a test pattern.** Confirm `framebuffer.c` is wired
   to the real UEFI GOP `BootInfo` and draw a simple orientation-revealing test pattern, using
   the existing raw pixel primitives only — no coordinate/Z machinery yet. *Refs:* §27.1.
 
-- [ ] **4.3.2 — QEMU screenshot capability.** Add a monitor/QMP socket to the `qemu` targets
+  > **Done, 2026-08-07.** `fb_draw_orientation_test()` added to `framebuffer.c`/`.h` — fills
+  > the four raster corners RED/GREEN/BLUE/YELLOW via `fb_fill_rect` only. Wired into
+  > `kernel_main.c` calling `fb_init()` directly; `console_fb_init()`/`vt100_init()` removed
+  > from the boot path per Captain Bob's direction (vt100.c/console.c are obsolete, superseded
+  > by the fabric redesign, not to be exercised even incidentally).
+  >
+  > **Bug found and fixed, not scope creep — the diagnostic did its job.** First screendump
+  > (via 4.3.2) showed a clean R↔B channel swap (G correct, R and B corners exchanged) —
+  > spatial placement was correct, so this ruled out flip/rotation but caught a real color
+  > bug: `framebuffer.c`'s `pack_pixel()` had its `FB_PIXEL_RGBX32`/`FB_PIXEL_BGRX32` branches
+  > swapped relative to UEFI GOP's own byte-order naming convention (pre-existing bug, not
+  > introduced this item). Fixed by swapping the two `pack_pixel` return bodies to match
+  > `framebuffer.h`'s already-correct doc comments; `kernel_main.c`'s GOP-format `switch`
+  > needed no change. Re-verified via a second screendump: all four corners render correctly
+  > (`fb/qemu-screenshot-20260807-113612.png`).
+  >
+  > Not addressed, not in scope: the pre-existing UEFI loader boot-log text remains visible
+  > behind the corner blocks, since this diagnostic paints four small rectangles and does not
+  > clear the framebuffer — expected, not a bug.
+
+- [x] **4.3.2 — QEMU screenshot capability.** Add a monitor/QMP socket to the `qemu` targets
   (mirroring the existing serial-socket pattern) so `screendump` can be issued and the 4.3.1
   test pattern actually inspected. None exists today — all three targets currently run with
   `-display none` and no monitor attached. *Refs:* §27.2.
 
+  > **Done, 2026-08-07 — mechanism already existed, didn't need building.**
+  > `scripts/qemu_screenshot.sh` was already a complete, working amd64 screendump path
+  > (monitor UNIX socket + `socat` + HMP `screendump`), just not wired into any
+  > `Makefile.starkernel` target and not previously exercised this session — 34 prior
+  > screenshots already sat in `logs/` from earlier use. Changed: output PNG now goes to a
+  > new top-level `fb/` directory (tracked in git, per Captain Bob — not `logs/`, not a
+  > gitignored temp dir); added a `python3`+PIL fallback for PPM→PNG conversion since
+  > `imagemagick` isn't installed on this machine. Left as a standalone script, not wired into
+  > a Makefile target, per direction — run directly for now. aarch64/riscv64 not covered by
+  > this script; not needed for 4.3.1's amd64-only diagnostic.
+
 - [ ] **4.3.3 — Cartesian coordinate machinery.** Origin bottom-left `(0, 0)`, Y-up, plus a
   new Z axis (depth-into-screen, not height) and a fixed orthographic projection as a
   placeholder — not the final projection, no perspective/camera work yet. Angle open: true