TRIPOD.md: fix stale Immediate Goal section, Hera does not auto-spawn at boot

Item 0.1 pruned capsules/init.4th to Hera-alone; TRIPOD.md was never updated to match. Corrected to reflect current on-demand-birth reality and distinguish Artemis-the-storage-device (auto-attaches at boot, kernel_main.c) from Artemis-the-VM-patron (not auto-spawned). Partial closure of FABRIC-2.md item 5.3 -- the doc's broader shrink-to-three-lines scope remains open.

FABRIC-2.md

@@ -48,6 +48,19 @@ and recorded.
   Goal section still describes Hera spawning Hermes and Artemis automatically at boot — item
   0.1 undid that behavior, and the doc was never updated to match.
 
+  > **Pending edit fixed 2026-08-13; the item's larger scope (actually shrinking the four
+  > documents) remains open.** `TRIPOD.md`'s "Immediate Goal" section corrected: it now
+  > states plainly that Hera boots alone by design (confirmed live —
+  > `capsules/init.4th` births no other VM), that Hermes/Artemis-as-VM-patron births are
+  > on-demand via test tooling today (not automatic boot behavior), and separately notes
+  > that Artemis's block-storage *device* does auto-attach at the C level at boot
+  > (`kernel_main.c`'s M7.pre step) — distinct from, and not to be confused with, an
+  > Artemis VM patron birth. The acceptance criteria were reworded from "Hera spawns X"
+  > to "Hera can spawn X" to stop asserting automatic behavior that doesn't exist. This
+  > closes only the one stale claim this document already flagged — `ARTEMIS.md`,
+  > `HERMES.md`, `CONSOLE.md` were not read for similar staleness, and none of the four
+  > documents' actual line-count reduction (the item's real ask) has been attempted.
+
 ---
 
 ## B. Live and unmeasured — deferred while Tripod was pruned to Hera-alone, now genuinely live since item 4.2 restored Hermes