fb/: untrack and gitignore -- throwaway local verification images

Reversing the earlier decision to track fb/ in git (made when first
setting up the directory for item 4.3.2). Captain Bob: these are
disposable screenshots for eyeballing framebuffer output during Console
work, never meant to be committed. Removed from git tracking (git rm
--cached) and added to .gitignore; files that still exist locally are
untouched, deletions already made locally are left as-is.

Also fixes item 4.3.4's amd64-only blind spot found in the process:
aarch64/riscv64 had no framebuffer device at all (GOP: protocol not
found) -- the "all three architectures boot clean" checks run all session
were REPL/dict_hash parity, a different thing from GOP presence, and
conflating the two was an error. Added -device ramfb (EDK2's
firmware-only GOP framebuffer) to both architectures' qemu targets in
Makefile.starkernel. Both now report GOP: linear framebuffer found at
800x600; cube rendering verified correct on both (screenshots not
committed, per the untrack above -- verified visually this session).
Standard three-arch acceptance boot re-run afterward, all clean,
dict_hash identical and unchanged from before this fix.

.gitignore

@@ -34,6 +34,10 @@ experiments/**/results/*.log
 Thumbs.db
 qemu.log
 
+# Framebuffer/Console screendumps — throwaway local verification images,
+# never meant to be committed (Captain Bob, 2026-08-07)
+fb/
+
 # Serial acceptance logs and session directories are audit artifacts — tracked in git
 # logs/ and logs2/ are intentionally NOT ignored
 # EXCEPTION: ECW-trace sessions generate 500-638MB logs that exceed GitHub's 100MB

FABRIC.md

@@ -3691,6 +3691,13 @@ document and committing that amendment as its own item.*
   > `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.
+  >
+  > **Reversed same day.** `fb/` is now gitignored after all (Captain Bob: these are
+  > throwaway local verification images, never meant to be committed). Screenshot paths
+  > cited in this document's other acceptance notes (4.3.1, 4.3.3, 4.3.3b, 4.3.4) still
+  > describe what was actually seen at the time, but those files are local-only now, not
+  > retrievable from git history in their originally-committed form — the commits that added
+  > them are still in history, just superseded by the untrack commit that follows.
 
 - [x] **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
@@ -3818,6 +3825,21 @@ document and committing that amendment as its own item.*
   > face square offset diagonally up-right by exactly the 45° cavalier projection's
   > depth term, all 12 edges connecting at the right corners, no crossed or broken lines.
   >
+  > **Correction, same day: the first pass above was amd64-only, and that wasn't flagged.**
+  > Asked for cube screenshots on all three ISAs surfaced that aarch64 and riscv64 had no
+  > framebuffer device at all — both booted with `GOP: protocol not found`. The "all three
+  > architectures boot clean" acceptance checks run all session were REPL/`dict_hash`
+  > parity, a different axis entirely from GOP/framebuffer presence; conflating the two was
+  > an error. Fixed by adding `-device ramfb` (EDK2's firmware-only GOP framebuffer, no
+  > guest driver needed) to both architectures' `qemu`/`qemu-esp` targets in
+  > `Makefile.starkernel`. Both now report `GOP: linear framebuffer found` at 800×600 (vs.
+  > amd64's 1280×800 via `q35`'s implicit default device — no code assumes a fixed
+  > resolution, so this required no changes elsewhere). Re-ran the same cube test on both:
+  > `fb/aarch64/cube-4.3.4.png` and `fb/riscv64/cube-4.3.4.png`, both correct. Re-ran the
+  > standard three-arch acceptance boot afterward — all still clean, `dict_hash` identical
+  > across all three and unchanged from before this fix (a QEMU device flag, not a kernel
+  > change).
+  >
   > **This is the checkpoint** — 4.3.x groundwork stops here for review per this item's own
   > acceptance criterion, before scoping whatever comes next.
 

Makefile.starkernel

@@ -816,6 +816,7 @@ else ifeq ($(ARCH),aarch64)
 		-drive if=virtio,format=raw,file=$(QEMU_ISO),media=cdrom \
 		-drive id=artdisk,file=$(ARTDISK),format=raw,if=none \
 		-device virtio-blk-pci,drive=artdisk \
+		-device ramfb \
 		-chardev socket,id=cserial,path=$$SERIAL_SOCK,server=on,wait=off,logfile=$$LOG \
 		-serial chardev:cserial \
 		-display none \
@@ -915,6 +916,7 @@ else ifeq ($(ARCH),riscv64)
 		-device virtio-blk-pci,drive=hd0,addr=0x2 \
 		-drive id=artdisk,file=$(ARTDISK),format=raw,if=none \
 		-device virtio-blk-pci,drive=artdisk,addr=0x1 \
+		-device ramfb \
 		-chardev socket,id=cserial,path=$$SERIAL_SOCK,server=on,wait=off,logfile=$$LOG \
 		-serial chardev:cserial \
 		-display none \