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

FABRIC-3.md

@@ -3201,3 +3201,81 @@ files; transform: lint/manifest/conflict-resolve; load: C-source generation) was
 idea, to be done as its own clean pass once the workload-into-factorial design (the actual
 reason this was scoped) resumes.
 
+## XXV. Ephemeral-birth workload design pivot; BIRTH/CAPSULE-BIRTH extended symmetrically; a
+real, pre-existing ACL lockdown gap found live and flagged, not fixed (2026-09-12)
+
+**The workload-into-factorial design got a real architectural improvement from stepping back
+and naming the project's own governing principle out loud.** Bob's own framing: "the trick is to
+make system calls, schedulers and filesystems more or less go away and at the same time
+introduce more automanagement and make that shit obsolete." Applied directly: the original two
+workload-placement options (`EXEC` a workload capsule into an already-running identity as an
+extra task, or in place of its std79 tests) both mutate a long-lived, ACL-locked identity's own
+persistent dictionary -- exactly the filesystem-shaped, policy-heavy mechanism the principle
+argues against, and it doesn't even dodge the block-collision exposure just traced in §XXIV, it
+just relocates it. The better fit, and Bob's reaction once it was named: "oh that's brilliant. i
+love it. heck, yes!" -- **a workload runs as a fresh, ephemeral child VM, `BIRTH`'d per trial and
+reaped after**, living its whole heat/reservoir/residency lifecycle in Stadium the same way any
+other VM does. No dictionary mutation, no permanent addition to an identity's own word set.
+Placement mode becomes a genuine third factor value alongside the original two, not a
+replacement for them.
+
+**Identity, decided explicitly rather than left ambiguous:** a workload trial run this way is
+still born under the specific identity's own name/lineage -- confirmed technically sound, not
+just conceptually: `CAPSULE-BIRTH ( capsule-id -- vm-id-hi vm-id-lo )` already passes
+`vm->stadium_vm_id` -- "who is birthing this VM" -- as the new child's parent, not a hardcoded
+Hera constant (`mama_word_capsule_birth`, checked directly, not assumed). Whichever VM actually
+calls it becomes the real, structural parent.
+
+**Which surfaced a real premise check: only Hera could call `BIRTH`/`CAPSULE-BIRTH` at all.**
+Both words were registered only inside `register_mama_forth_words()` -- confirmed directly in
+`mama_forth_words.c` (lines ~1620/1678 for `BIRTH`, ~1632/1690 for `CAPSULE-BIRTH`, both strictly
+before `register_child_vm_words()`'s own start) -- not part of the §XX messaging-symmetry fix,
+which deliberately *kept* `BIRTH` as one of Hera's remaining real privileges. Extending it now is
+its own deliberate step, agreed explicitly before touching code, not assumed to already be done.
+
+**Symmetric registration alone can't weaken any personality's own lockdown, confirmed by reading
+the mechanism rather than assumed:** `acl-std79.4th`'s `ACL-LOCKDOWN-STD79` is allowlist-based,
+deny-by-default -- it walks the *entire* 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. Fixed in two pieces:
+
+- **`mama_forth_words.c`**: `BIRTH` and `CAPSULE-BIRTH` added to `register_child_vm_words()`,
+  matching the exact §XX symmetric-registration pattern.
+- **`acl-std79.4th`**: `' BIRTH , ' CAPSULE-BIRTH ,` added to `ACL-STD79-LIST` (new block 4048),
+  with the header comment updated to name this as the one deliberate non-FORTH-79/83 exception
+  it now is -- a real, conscious tradeoff against the lockdown's own "standard words only"
+  guarantee, not a free lunch, made explicitly rather than slipped in silently.
+
+**Verified end to end:** clean build on all 3 architectures, zero new warnings. Hera's own
+dict_hash is unchanged (expected -- only `register_child_vm_words()` changed); Hermes/Artemis
+both show the new dict_hash `0xf53a0baccd073321`/`0x859932264267b042`, identical across all 3
+architectures -- confirmed by booting each, not assumed from one. Live-tested against a real
+attached identity (`rajames`, std79-locked): `S" 99999 CAPSULE-BIRTH . ." S" rajames" VM-EXEC`
+correctly executed and returned `vm_uuid_none()`'s sentinel (`-1 -1`) for the deliberately
+out-of-range capsule-id, with zero fault and zero ACL denial -- the carve-out works.
+
+**A genuine, separate, pre-existing gap found live while verifying the ACL carve-out, not caused
+by it:** `MSG-STATUS` and `MSG-K` -- `common:messaging.4th` words, not on `ACL-STD79-LIST` --
+both executed successfully for `rajames` rather than being denied. `ACL-LOCKDOWN-STD79` is
+confirmed to actually run (`capsule_mint.c`'s `MINT_RESTRICTED_PERSONALITY`, block 4998, calls it
+as the VM's own last bootstrap step), so this isn't "the lockdown never engages" -- something
+more specific isn't reaching messaging.4th's dictionary entries. One promising lead, not yet
+confirmed: `capsule_mint.c`'s `MINT_RESTRICTED_PERSONALITY` (block 4998) itself never loads
+`common:messaging.4th` at all -- only `MINT_DEFAULT_PERSONALITY` (block 4999) does -- so
+messaging must be reaching a std79-locked identity via some other, not-yet-traced per-identity
+init path, and the boot-order relationship between that load and `ACL-LOCKDOWN-STD79`'s own walk
+is exactly the open question. `REBOOT` (explicitly named excluded in the lockdown's own header
+comment) produced an error rather than clean success when tested the same way, though the
+console's generic `VM-EXEC: ERROR in rajames` message doesn't cleanly distinguish "ACL denied"
+from "some unrelated failure" -- inconclusive on its own, not contradicting the messaging-gap
+finding. **Explicitly stopped here at Bob's call, documented rather than chased to full root
+cause** -- this needs real tracing of `vm_core.c`'s dictionary-link mechanics and finding
+whichever capsule actually loads messaging for these identities, which is its own investigation,
+separate from the `BIRTH` work it was found while verifying.
+
+**Next step:** root-cause the messaging/lockdown gap as its own piece of work, then resume the
+workload-into-factorial design itself (sine/fib/square-wave as the three chosen workloads,
+workload-identity × placement-mode as two real factors, ephemeral-birth now the leading
+placement-mode candidate) once BIRTH's own verification (done here) and the ACL gap (flagged,
+not yet fixed) are both accounted for.
+