Multiuser DoE punch list: WORKER-BIRTH + VM-ERROR? + vm_physics_init fix

Core mechanism for §XXXIII's main concurrency block, built and
live-verified on amd64. Two new primitives:

- WORKER-BIRTH ( capsule-c capsule-u name-c name-u -- ok? ): births a
  named, VM-EXEC-addressable VM from an arbitrary (p) capsule with no
  identity involved. Corrects the ratified design's own assumption that
  the main block would use UNATTENDED-BIRTH -- that requires a
  committed capsule per identity, impractical for dozens of trial VMs.
  The concurrency block never needed identity at all.
- VM-ERROR? ( c-addr u -- flag ): reads a named VM's error state from
  Hera, mirroring VM-HEAT's silent/always-returns-a-value contract.
  Needed to check a VM-EXEC-driven trial VM's own fault state after
  the fact -- nothing existing let Hera do this.

Real bug found and fixed in both WORKER-BIRTH and UNATTENDED-BIRTH:
capsule_birth_baby() never calls vm_physics_init() either (same shape
as the registry-name gap found building UNATTENDED-BIRTH) -- without
it a born VM is never in the VM Fleet Attractor physics list, so
VM-HEAT returns 0 forever regardless of work done. Fixed by adding
vm_physics_init() alongside the existing registry-name call in both
words.

Traced (not guessed) why heat still read 0 after one VM-EXEC touch
even post-fix: vm_physics_touch()'s transfer logic only fires from a
VM's *second* touch onward -- the first touch just records a baseline
tick. Verified live across three sequential touches: heat 0 -> 7039 ->
11333. This is a real design requirement for the DoE's heat/CV
response variable (each trial must touch a worker at least twice), not
a bug to route around.

Also found live: all 10 existing workload-N.4th capsules self-execute
their full workload at load/birth time (a bare top-level call to their
own RUN-* word at file end) -- missed on an earlier, too-shallow
8-line survey of each file. WORKER-BIRTH alone already runs a worker's
first pass as a side effect of birth.

Verified live on amd64: two concurrent workers (fib + matrix-mul)
birthed, run, measured (heat + error state), and killed cleanly;
VM-HEAT/VM-ERROR? both confirmed silent-0 on an unknown name. Clean
3-arch qemu boot on the real committed change.

Still open: the run-matrix/shuffle/CSV driver capsule itself, the
WIREBIND-automation path for the fixed arm, and the per-VM touch-count
budget's exact value.

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

FABRIC-3.md

@@ -4936,3 +4936,58 @@ proven at this scale.
   standing convention, at least one full pass reviewed for plausibility before calling the
   harness itself proven.
 
+### XXXIII.4 -- Punch list progress, 2026-09-16: core mechanism built and live-verified
+
+**A scoping correction found immediately on starting implementation:** the ratified design's
+main block said "every concurrent VM is `UNATTENDED-BIRTH`'d." Wrong in practice --
+`UNATTENDED-BIRTH` requires its own committed capsule per identity (mint, hand-transcribe,
+author a `.4th` file), completely impractical to repeat for dozens of trial VMs across a real
+factorial. The main concurrency block never needed identity at all -- it's stressing
+concurrency and workload execution, not identity verification (already proven in §XXXII).
+**New primitive: `WORKER-BIRTH ( capsule-c capsule-u name-c name-u -- ok? )`** -- births a
+named, `VM-EXEC`-addressable VM from an arbitrary `(p)` capsule with no identity involved at
+all, built specifically for this main block. `UNATTENDED-BIRTH` stays exactly as built, for
+the fixed arm where identity origin is the thing being varied.
+
+**A second gap found the same way UNATTENDED-BIRTH's registry-name gap was found:**
+`capsule_birth_baby()` also never calls `vm_physics_init()` -- so a `WORKER-BIRTH`'d (and, it
+turns out, an `UNATTENDED-BIRTH`'d) VM was never registered in the VM Fleet Attractor physics
+list at all, making `VM-HEAT` return 0 forever regardless of how much work the VM did. Fixed
+in both words (`vm_physics_init(new_vm_id)` alongside the existing
+`capsule_vm_registry_set_name()` call) -- plain `BIRTH` was the only existing caller doing
+both together, another instance of "every birth caller must do these steps itself,
+`capsule_birth_baby()` sets neither."
+
+**A real design requirement for the heat/CV response variable, traced to ground truth in
+`vm_physics_touch()` rather than guessed at:** heat only transfers from a VM's *second* touch
+onward -- the first touch on any VM only records a baseline tick and sets `touched=1`, moving
+zero heat by construction (`capsule_vm_physics.c:301-303`'s own gating condition). Verified
+live: heat read `0` after one `VM-EXEC` touch, `7039` after a second, `11333` after a third.
+**Design requirement, not a bug to route around:** each trial's per-worker driving sequence
+must call `VM-EXEC` at least twice for heat to be a meaningful signal at all.
+
+**New primitive: `VM-ERROR? ( c-addr u -- flag )`** -- reads a named VM's `vm->error` state
+from Hera, mirroring `VM-HEAT`'s exact "silent, always returns a value" contract (0 on unknown/
+dead name, no error). Needed because nothing previously let Hera check a `VM-EXEC`-driven
+trial VM's own fault state after the fact.
+
+**Live-verified end to end on amd64:** birthed two concurrent workers (`w1` from
+`workload-8.4th`/fib, `w2` from `workload-7.4th`/matrix-mul) via `WORKER-BIRTH`, confirmed both
+alive and running distinct real workloads simultaneously, read heat and error state on both
+after driving real work through `VM-EXEC`, confirmed `VM-HEAT`/`VM-ERROR?` both return silent 0
+(no crash) for a nonexistent name, and `KILL`'d both cleanly. Separately verified the
+heat-transfer mechanism itself across three sequential touches on one worker. Hera stayed
+healthy throughout every test (`5 6 + .` -> `11` after each). Clean 3-arch qemu boot on the
+real committed change.
+
+**Also found, not chased:** every one of the 10 existing `workload-N.4th` capsules
+self-executes its full workload immediately at load/birth time (a bare top-level call to its
+own `RUN-*` word at the end of the file) -- confirmed by reading each file's actual tail, not
+assumed from its first ~10 lines as an earlier pass of this investigation did. This means
+`WORKER-BIRTH` alone already runs a worker's assigned workload once as a side effect of birth;
+no separate "load then call" step is needed for that first run, only for subsequent
+`VM-EXEC`-driven touches.
+
+**Still not started:** the run-matrix/shuffle/CSV driver itself, the WIREBIND-automation path
+for the fixed arm, and the per-VM iteration/touch-count budget's exact value.
+