Test: make cooperative nursery rendezvous witness deterministic under sharding

Parents: #476, #494 Related: #491

Problem

The unit test parallel_js: cooperative shared nursery rendezvous bounds object churn is scheduler-sensitive in the eight-shard full inventory. Twice on current main plus an unrelated one-file change, both worker results were exact but gc_cooperative_attempts remained zero, failing the first telemetry assertion after roughly 8 to 9 seconds. The exact isolated test passed immediately after each failure in roughly 3.7 seconds with all rendezvous assertions intact.

Observed full-suite records:

• #671 landing run: 1765 passed, 1 skipped, this one failure; exact focused rerun passed; complete rerun then passed 1766 plus 1 skip.
• #672 verification run: 1766 passed, 1 skipped, this one failure; exact focused rerun passed.

The test comment claims its two lanes necessarily exceed the frozen 512 KiB tranche, so a zero-attempt outcome means either the witness does not actually force the intended allocation accounting path under shard scheduling or the test reads the wrong lifecycle boundary. Repeating the test until it happens is not evidence.

Scope

• Determine why the sharded run can complete exact JS work with zero cooperative attempts.
• Make the witness deterministically cross the production tranche through real Object-class allocation accounting.
• Preserve the production tranche, rendezvous deadlines, allocator/GC behavior, and all telemetry equalities.
• Keep one exact focused runtime budget and verify repeated sharded placement.

No-workaround rules

• No lowered production threshold, sleeps, retry-until-pass loop, weakened or deleted telemetry assertion, synthetic counter mutation, disabled sharding, blanket timeout increase, or sanitizer suppression.
• No Thread lifecycle, stack, queue, job, Promise, Worker, or Map/Set iterator implementation changes.

Acceptance

• Root cause explains the zero-attempt sharded outcome.
• The test deterministically records attempts, collections, peer parks, phase bytes/times, and zero unsanitized timeouts.
• At least 20 repeated focused executions and repeated eight-shard placements pass with exact checksum and no leaks.
• Debug, ReleaseSafe, and TSan retain the production GC contract and functional result.
• Full units pass without retrying a failed inventory.

Root cause confirmed: cooperative allocation tracking is armed only when the second worker record is registered. The witness constructed the first Thread and then the second, so under heavy shard scheduling the first worker could complete most or all of its 2400-object churn before tracking became active. One remaining tracked lane is below the frozen 512 KiB tranche, making zero attempts a valid outcome even though both worker results are exact.

The test-only candidate now uses a SharedArrayBuffer Atomics rendezvous before either lane allocates. Reaching two ready workers proves that the second record, tracking, and both active interpreters exist before the real Object-class churn crosses the unchanged tranche. It does not alter Thread lifecycle, GC policy, deadlines, counters, retry behavior, or any stack, queue, job, Promise, Worker, or Map/Set implementation.

Completed evidence on exact Zig 0.17.0-dev.1818:

• Debug focused: 20/20 repeated executions passed, exact checksum, zero failures, zero leaks; 3.60 to 3.97 seconds each.
• ReleaseSafe focused: 1/1 passed, zero leaks, 17 ms.
• TSan focused: 1/1 passed, zero races/failures/leaks, 32.356 seconds.
• All original telemetry assertions remain unchanged, including attempts, collections, peer parks, phase accounting, and zero unsanitized timeouts.

Repeated eight-shard placement and the one-shot full inventory remain pending a quiet host window. An unrelated 11-core local TypeScript conformance job is active now, so starting them would create the starvation condition documented by the repository rather than valid evidence.

Landed on main as test(gc): synchronize cooperative tranche witness (#673).

The first worker previously could allocate before the second Thread record armed shared allocation tracking. Both workers now rendezvous before allocating, so the unchanged 512 KiB tranche is crossed through real tracked 128-byte Object-class cells while both interpreters are active.

Final evidence on Zig 0.17.0-dev.1818:

• Debug focused: 20/20 passed, exact checksum, zero failures/leaks.
• Eight-shard cooperative placement: 3/3 runs passed; 12 tests total, zero failures/leaks.
• ReleaseSafe: 1/1 passed, zero leaks.
• TSan: 1/1 passed, zero races/failures/leaks.
• One-shot full units: 1767 passed, 1 skipped, 0 failed, 0 leaked; target passed in its shard in 5.497 seconds.
• Test262 flips: 0; this is a deterministic test witness only.

No threshold, deadline, allocator/GC policy, lifecycle, counter, retry, sanitizer, stack, queue, job, Promise, Worker, or Map/Set implementation changed.