Hera can't message: root-caused and fixed by symmetry (FABRIC-3.md §XX)

Hera never loaded common:messaging.4th, unlike every other VM in the
fleet. The standing belief was this was deliberate, to avoid moving
her dict_hash off baseline. Checked live instead of assumed: loading
messaging.4th into her dictionary silently dropped every colon-
definition referencing one of 8 STADIUM-* primitives that
register_child_vm_words() gives every other VM but
register_mama_forth_words() never gave her -- a missing-primitive gap,
not a designed privilege boundary. Confirmed mama_word_birth is
genuinely VM-agnostic and SPAWN-EVENT is an unwired placeholder before
proposing the fix.

Fix: register the same 8 STADIUM-* primitives for Hera, load
messaging.4th from init.4th the same way Hermes/Artemis/console/mint
already do, and give her own idle-loop context a direct MSG-TICK call
(not VM-EXEC, which would hit the same reentrancy class the existing
per-other-VM pump loop already guards against) so her own queued
messages actually drain. Her dictionary is now a proper superset of
every child VM's, plus her remaining extra privileges -- not
structurally different from any other VM, just additionally
privileged.

Verified: dict_hash identical across amd64/aarch64/riscv64
(0xc8f4b09e36f4fc4a), Hermes/Artemis dict_hashes unchanged and still
cross-arch identical, all three boot clean to zuse)ok> with zero
UNKNOWN WORD faults, mkcapsule --lint clean.

Unblocks rewriting the turn-attractor (FABRIC-3.md §XIX) to coordinate
via real MSG-SEND/MSG-TICK instead of blocking VM-EXEC.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo

src/starkernel/repl.c

@@ -621,6 +621,22 @@ static void sk_repl_idle(VM *active_vm)
             vm_interpret(mama, cmd);
         }
     }
+    /* FABRIC-3.md SXX: Hera now genuinely has her own MSG-ARENA/CH-ARENA
+     * (the messaging-load root cause above is fixed -- see kernel_main.c's
+     * own updated comment at the Hermes-birth call site), so her own
+     * queued messages need draining too, same as every other VM's. She's
+     * excluded from the loop above not because she lacks MSG-TICK now, but
+     * because she IS the pump -- self-targeting VM-EXEC would hit the same
+     * reentrancy class the guard above exists for. No such problem calling
+     * MSG-TICK directly here, though: it's a plain word in her own
+     * dictionary, not a VM-EXEC dispatch into anyone else's input buffer.
+     * Guarded the same defensive way as the loop above, not assumed. */
+    {
+        DictEntry *msgtick = vm_find_word(mama, "MSG-TICK", 8);
+        if (msgtick && msgtick->acl_allow) {
+            vm_interpret(mama, "MSG-TICK");
+        }
+    }
     g_idle_pump_active = 0;
 
     if (console_tx_count() == tx_before_idle) {