Extend BIRTH/CAPSULE-BIRTH to all VMs symmetrically; flag a real std79 lockdown gap (FABRIC-3.md §XXV)

Scoping the workload-into-factorial design's placement-mode factor
led to a real architectural improvement: rather than EXEC-ing a
workload capsule into an already-running, ACL-locked identity's own
persistent dictionary (filesystem-shaped, doesn't dodge the block-
collision exposure just traced in §XXIV), a workload now runs as a
fresh ephemeral child VM, BIRTH'd per trial and reaped after --
matching the project's own stated principle of automanagement over
imposed policy. CAPSULE-BIRTH already passes vm->stadium_vm_id (who
is birthing this VM) as the new child's parent, not a hardcoded Hera
constant, confirmed by reading the C -- so a workload trial genuinely
inherits the specific identity's own lineage when that identity does
the birthing.

Which surfaced a real premise: only Hera could call BIRTH/
CAPSULE-BIRTH at all (registered only in register_mama_forth_words(),
confirmed directly, not part of the earlier §XX messaging-symmetry
fix which deliberately kept this as one of her remaining privileges).
Extended symmetrically now, agreed explicitly before touching code:

- mama_forth_words.c: BIRTH and CAPSULE-BIRTH added to
  register_child_vm_words(), matching §XX's own pattern.
- acl-std79.4th: ' BIRTH , ' CAPSULE-BIRTH , added to ACL-STD79-LIST
  (new block 4048) -- a deliberate, explicit, named exception to the
  lockdown's own "standard words only" guarantee, not a silent one.
  Symmetric registration alone can't weaken any lockdown on its own:
  ACL-LOCKDOWN-STD79 is allowlist-based, deny-by-default, so a newly
  registered word is auto-denied there unless explicitly added.

Verified: clean build on all 3 architectures, zero new warnings.
Hera's own dict_hash unchanged (expected); Hermes/Artemis show the
same new dict_hash on all 3 architectures. Live-tested against a
real attached std79-locked identity: CAPSULE-BIRTH executes
correctly (returns vm_uuid_none() for a deliberately out-of-range
capsule-id, zero fault, zero ACL denial).

Found, and explicitly stopped short of fixing, a separate pre-
existing gap while verifying the above: MSG-STATUS and MSG-K
(messaging.4th words, not on the std79 allowlist) execute for a
locked identity instead of being denied. ACL-LOCKDOWN-STD79 is
confirmed to actually run; something more specific isn't reaching
messaging.4th's dictionary entries. Root cause not traced -- needs
its own investigation into vm_core.c's dictionary-link mechanics and
whichever capsule actually loads messaging for these identities.

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

src/starkernel/capsule/mama_forth_words.c

@@ -1955,6 +1955,20 @@ void register_child_vm_words(VM *vm)
     register_word(vm, "STADIUM-HEAT@",    mama_word_stadium_heat_fetch);
     register_word(vm, "STADIUM-HEAT!",    mama_word_stadium_heat_store);
     register_word(vm, "STADIUM-WORD-HEAT", mama_word_stadium_word_heat);
+    /* FABRIC-3.md SXXV (2026-09-12): BIRTH/CAPSULE-BIRTH were Hera-only by
+     * registration alone -- both mama_word_birth() and mama_word_capsule_
+     * birth() were already genuinely VM-agnostic underneath (the latter
+     * explicitly passes vm->stadium_vm_id, "who is birthing this VM," not
+     * a hardcoded Hera constant -- confirmed by reading the C before
+     * assuming it). Symmetric registration alone can't weaken any
+     * personality's own ACL lockdown: acl-std79.4th's ACL-LOCKDOWN-STD79
+     * is allowlist-based, deny-by-default -- it walks the WHOLE
+     * dictionary and denies+pins anything not on ACL-STD79-LIST, so a
+     * newly-registered word is auto-denied there unless a human
+     * deliberately adds it (which acl-std79.4th now does, explicitly,
+     * for exactly these two -- see its own updated comment). */
+    register_word(vm, "BIRTH",         mama_word_birth);
+    register_word(vm, "CAPSULE-BIRTH", mama_word_capsule_birth);
 }
 
 #endif /* __STARKERNEL__ */