starkernel: remove item 4.3.1's orientation-test corner blocks from boot

fb_draw_orientation_test() was a one-time diagnostic for 4.3.1 (raw GOP
framebuffer wiring), already [x] done. With 4.4c's vt100 console now live,
the corner blocks just obscure real console output in every screendump.
Function definition left in framebuffer.c/framebuffer.h for future reuse;
only the boot-time call site is removed.

Also commits routine log/manifest housekeeping: capsules/BLOCK_MAP.md
(regenerated by mkcapsule on each build), the amd64 probe logs from before
today's outage, and the screendump logs + evidence screenshot from this
session's 4.4c/4.4d/4.4e verification.

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

capsules/BLOCK_MAP.md

@@ -1,5 +1,5 @@
 # Capsule Block Manifest — Auto-generated
-<!-- Generated by mkcapsule --manifest  2026-08-11T11:35:25Z -->
+<!-- Generated by mkcapsule --manifest  2026-08-11T12:37:12Z -->
 <!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh.  -->
 <!-- Hand-written justifications and immutability notes live  -->
 <!-- in MANIFEST.md alongside this auto-generated index.      -->

src/starkernel/kernel_main.c

@@ -827,15 +827,20 @@ static void kernel_main_deep(BootInfo *boot_info) {
 #endif
 
     /*
-     * FABRIC.md item 4.3.1 -- raw framebuffer boot diagnostic, plus 4.4c
-     * (2026-08-11): console_fb_init() wires the framebuffer AND turns on
-     * vt100_init(), so serial and framebuffer consoles carry identical
-     * output from here on -- Captain Bob's stated end goal. Previously only
-     * raw fb_init() ran and console.c/vt100.c's framebuffer path was
-     * deliberately skipped ("superseded by the Console drawing-fabric
-     * redesign"); that left vt100_putc() permanently uninitialized and no
-     * console output ever reached the screen. console_fb_init() calls
-     * fb_init() internally, so this replaces the old call, not adds to it.
+     * FABRIC.md item 4.4c (2026-08-11): console_fb_init() wires the
+     * framebuffer AND turns on vt100_init(), so serial and framebuffer
+     * consoles carry identical output from here on -- Captain Bob's stated
+     * end goal. Previously only raw fb_init() ran and console.c/vt100.c's
+     * framebuffer path was deliberately skipped ("superseded by the Console
+     * drawing-fabric redesign"); that left vt100_putc() permanently
+     * uninitialized and no console output ever reached the screen.
+     * console_fb_init() calls fb_init() internally, so this replaces the
+     * old call, not adds to it.
+     *
+     * fb_draw_orientation_test() (item 4.3.1's one-time diagnostic, already
+     * [x] done) removed 2026-08-11 -- its corner test blocks were only
+     * needed to verify the raw GOP framebuffer wiring once; now that vt100
+     * is live, they just obscure real console output in every screendump.
      */
     if (boot_info->framebuffer.base != NULL && boot_info->framebuffer.size > 0) {
         FbPixelFormat fb_fmt;
@@ -845,7 +850,6 @@ static void kernel_main_deep(BootInfo *boot_info) {
             default: fb_fmt = FB_PIXEL_BGRX32; break;
         }
         console_fb_init(&boot_info->framebuffer, fb_fmt);
-        fb_draw_orientation_test();
     }
 
     /* Clear reboot-tries counter: we reached the REPL cleanly */