Verify turtle.4th rendering live, revert overdue ART-STRESS-CAMPAIGN disable

Disabled capsules/artemis/init.4th block 4170's ART-STRESS-CAMPAIGN -- its
own comment already said to revert to disabled once the K-invariant/
heartbeat verification run (item 4.6, closed earlier this session) was
done. This was the actual ~25-30 minute wall blocking interactive REPL
access, unrelated to any DoE mechanism.

Verified capsules/turtle.4th and capsules/sdk.4th live in a gtk-display
QEMU session: a red hexagon (6 100 POLYGON) and a green self-intersecting
star (100 STAR) both render with correct geometry and color. Screenshot in
evidence/amd64/.

Two real obstacles found and worked around along the way: CS's full-
framebuffer PLOT loop is far slower under TCG than previously documented
(closer to 20+ minutes than "slow"), and the kernel's heartbeat CSV logging
draws to the same console surface PLOT writes pixels to, overwriting
drawings within a fraction of a second unless silenced first with the
existing HB-OFF word. Both HOWTOs updated to record this.

Re-verified full three-arch acceptance boot (POST, DoE, parity) with the
ART-STRESS-CAMPAIGN change: 1012/0/0 and matching dict_hash on all three,
identical to the pre-change baseline.

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

FABRIC-2.md

@@ -1830,8 +1830,53 @@ Not yet driven interactively through a live REPL, same DoE-before-REPL practical
 `turtle.4th`'s own still-open item.
 
 This closes the mechanism + capsule work for SDK v1.9.0 scoping. Still open, not decided here:
-the `1.5.4`→`1.9.0` version-string bump itself, and whether to verify `turtle.4th`'s actual
-rendering before treating either it or this SDK as release-ready — both are release-process
-decisions, not implementation work, and belong to the user's call per the same pattern used
-throughout this scoping (`AskUserQuestion` for the calls that are genuinely the user's, not
-inferred).
+the `1.5.4`→`1.9.0` version-string bump itself. `turtle.4th`'s rendering — the other open
+item — was resolved next, below.
+
+## L. `turtle.4th` rendering verified live — and a real, overdue capsule revert found doing it — 2026-08-19
+
+User's explicit instruction: disable the DoE wall and verify turtle rendering interactively.
+First correction: the actual blocker was never any DoE mechanism from section K's "which DoE?"
+survey — it's `capsules/artemis/init.4th` block 4170's `ART-STRESS-CAMPAIGN`, which auto-runs
+unconditionally at Artemis's birth (itself unconditionally triggered by a `kernel_main.c`
+self-test at every boot). Block 4170's own comment already said what to do: *"TEMP: 30-
+replicate campaign enabled for the K-invariant/heartbeat verification run. Revert to `\
+ART-STRESS` (disabled) once that run is done."* That run was item 4.6, closed earlier this
+session (Section H) — the revert was already overdue, not a new decision. Reverted to
+`\ ART-STRESS-CAMPAIGN` (disabled), matching the file's own stated intent exactly.
+
+**Screenshot methodology, since this codebase's tooling had none.** No QEMU monitor socket is
+configured by `Makefile.starkernel`'s `qemu` target (no `screendump` path), and this
+environment has no `import`/`ImageMagick`/`netpbm`. Used `spectacle -b -f -n -o <file>` (KDE's
+screenshot utility, background mode) against the real X11 session already running on this
+machine, then cropped to the QEMU window with a one-off PIL script — landed the result in
+`evidence/amd64/` following the existing `qemu-screenshot-<timestamp>-<description>.png`
+convention (first entry in that directory since 2026-08-11's console work).
+
+**Two genuine, previously-undocumented obstacles found and worked around, not just a slow
+wait.** First attempt: launched, waited, and by the time `TURTLE-DEMO` (which calls `CS` before
+drawing) finally returned to the prompt, someone had typed directly into the QEMU window itself
+(visible in the log as a literal typo sequence — `vye`, `bye`, `b bye`, then `BYE`) and cold-
+restarted the machine before a screenshot could be taken. Established from this: (1) `CS`'s
+full-framebuffer nested `PLOT` loop is far slower than the existing "slow under TCG" caveat
+suggested — it consumed essentially this session's entire ~20+ minute runtime for one clear,
+not a minor delay; (2) the kernel's heartbeat CSV logging (`[HADES][DOE ]` rows, from
+`src/starkernel/doe_log.c`) draws to the *same* console surface `PLOT` writes pixels to, and
+scrolls continuously — anything drawn is visually overwritten within a fraction of a second
+regardless of timing, which is *why* nothing was visible in an earlier screenshot taken while
+the console was still scrolling (not a "didn't wait long enough" problem, a "wrong surface
+staying dirty" problem). `doe_log.c` already registers `HB-OFF`/`HB-ON` for exactly this
+purpose (silence/re-enable per-tick console output, `g_doe_log_enabled` flag) — calling
+`HB-OFF` before drawing, and skipping `CS` in favor of calling `HOME`/`SETCOLOR`/`POLYGON`/
+`STAR` directly, produced a clean, fast, visually correct result on the next attempt.
+
+**Verified:** `S" sdk.4th" EXEC` loads live (banner prints), `HB-OFF` silences heartbeat output,
+`HOME 16711680 SETCOLOR 6 100 POLYGON` draws a correct red hexagon, `HOME 65280 SETCOLOR 100
+STAR` draws a correct green self-intersecting five-pointed star below it — both geometrically
+correct, both the requested colors, zero VM errors on any call. Screenshot:
+`evidence/amd64/qemu-screenshot-20260819-074637-turtle-polygon-star-verified.png`. Both HOWTOs
+(`TURTLE-GRAPHICS-HOWTO-20260819.md`, `SDK-HOWTO-20260819.md`) updated to record this and the
+two obstacles/workarounds, replacing their earlier "not yet visually confirmed" caveats.
+
+This closes the last open item from SDK v1.9.0 scoping's own list. Only the version-string bump
+remains, and it's a release decision, not implementation work.