GC: publish provisional VM activation roots failure-atomically

[chrisbbreuer]

Parent: #786
Related: #477, #493

Audit finding

Interpreter.pushExecRoot currently discards gc_execs.append allocation errors. A failed root-list growth can therefore run bytecode without registering its precise roots. Separately, buildActivation installs callee state and performs argument/rest/parameter/debugger allocations before execLoop or runDriver registers its Exec. Saved caller state and newly prepared frame slots need precise ownership during that provisional window too.

This is a pre-existing publication/lifecycle issue found while fixing the stale saved caller copies in #786; it is not solved by moving those copies into Exec alone.

Scope and acceptance

• Root registration propagates allocation failure before executing an unregistered activation.
• Provisional activation preparation publishes all live managed caller/callee state before any allocation-recovery or observable call boundary.
• Every error path restores the caller and unregisters/recycles exactly the records it owns, including tail replacement and driver-list growth failures.
• Deterministic allocation-failure sweeps and moving-GC witnesses cover initial, inline, nested-driver, and tail-call entries.
• Normal/TSan/OOM and required integration gates pass with no ignored allocation errors, pinning, disabled GC, or fallback.

Coordinate any activation-driver lifecycle changes with the actor handling stack/queue/job-native work; this issue must not change Promise, Worker, or iterator behavior.

[chrisbbreuer]

Follow-up source audit against b023626a identifies the concrete failure-injection boundaries for this lifecycle work:

• buildActivation debugger preparation: the environment allocation and binding puts use bare try after callee state installation. Unlike surrounding argument/rest/parameter failures, these exits do not restore/recycle the activation.
• runDriver: initial list growth has explicit cleanup, but nested list growth, debugger synchronization, native-entry errors, and return-value delivery can leave through bare try while owned activations remain registered. The handler-delivery appends in unwindThrow require the same audit.
• execLoop root entry: scratch/binding storage preparation precedes root registration, and registration currently cannot report failure. The inline caller has a restoration defer once buildActivation succeeds; the ownership contract must cover the earlier preparation window too.

A coherent fix should define one provisional-to-running ownership handoff, then inject allocation failure at each entry/append/sync/handler/return boundary and assert caller state, logical depth, precise-root list, pending activation, and reusable activation state are restored exactly. Actual moving-GC probes should force collection during preparation, not only inside the eventual instruction loop.

This is read-only audit evidence, not a claimed repro or implemented fix. I have left activation-driver/stack lifecycle implementation untouched for coordination with the reserved native stack/queue/job work.