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>

docs/working/architecture/TURTLE-GRAPHICS-HOWTO-20260819.md

@@ -132,9 +132,26 @@ rather than a `POLYGON` call with `n=5`.
   `Makefile.starkernel ARCH=amd64` build, zero warnings; boot verified
   clean through POST and into the DoE campaign with the capsule present
   (not autoloaded, so it cannot affect the boot path it isn't on).
-- Not yet visually confirmed pixel-by-pixel in a live framebuffer (that
-  requires an interactive `gtk`-display QEMU session with a human at the
-  keyboard, or driving the serial socket past the ~25–30 minute DoE
-  campaign that runs automatically before the REPL is reachable — neither
-  was practical to do unattended). The arithmetic and control flow are
-  verified; the actual rendered image is not.
+- **Visually confirmed 2026-08-19**, live in a `gtk`-display QEMU session:
+  a red `6 100 POLYGON` (hexagon) and a green `100 STAR` both render with
+  correct geometry and color. Screenshot:
+  `evidence/amd64/qemu-screenshot-20260819-074637-turtle-polygon-star-
+  verified.png`. Two things had to be worked out first, worth recording
+  since they'll matter for any future interactive session:
+  - The `~25–30` minute wall this doc used to describe turned out to
+    actually be `capsules/artemis/init.4th`'s `ART-STRESS-CAMPAIGN`
+    (auto-runs at Artemis's birth, unrelated to any DoE mechanism
+    documented in `DOE-LIBRARY-HOWTO-20260819.md`) — it carried a stale
+    `TEMP: ... revert once that run is done` comment for a verification
+    run that had already closed. Reverted to disabled, matching the
+    file's own note (FABRIC-2.md section K/L).
+  - The kernel's heartbeat CSV logging (`[HADES][DOE ]` rows) draws to
+    the *same* console surface `PLOT` draws pixels to, and scrolls
+    continuously — anything drawn gets visually overwritten within a
+    fraction of a second unless silenced first with `HB-OFF` (registered
+    in `src/starkernel/doe_log.c`; `HB-ON` re-enables it). Do this before
+    drawing anything you want to actually see.
+  - `TURTLE-DEMO`'s own `CS` call turned out to be dramatically slower
+    than "slow under TCG" suggested — closer to 20+ minutes than a minor
+    delay, for a full-framebuffer nested `PLOT` loop. For a quick visual
+    check, call `HOME`/`SETCOLOR`/`POLYGON`/`STAR` directly and skip `CS`.