Perf: retain checkpoint-safe object allocation reserves #125

Parent: #97
Related: zig-utils/zig-gc#25, zig-utils/zig-gc#26

Evidence

The post-#120 exact shared object_churn profile resolves the hottest allocation wait to zig-gc metadata publication. zig-gc#26 removes the failed-CAS write storm and improves the exact eight-lane median 11.8%, but the VM still publishes a batch about every 17 objects because each quickened loop invocation stops at the 1,024-step checkpoint.

zig-gc#25 proved that shortening a 17-cell critical section alone is not general: its O(1) list splice regressed the lower shared lanes. The remaining lever belongs in zig-js: retain a bounded initialized-cell reserve as an explicit interpreter GC root so one larger publication can serve several checkpoint-bounded invocations safely.

Scope

• Add a bounded per-interpreter reserve used only by the guarded fixed-shape object-allocation quick path in parallel mode.
• Default-initialize every published cell before it enters the reserve and precisely trace only its unused suffix at every collection/root-publication path.
• Consume cells in allocation order, preserve short-prefix/OOM behavior, and never carry an unpublished or uninitialized cell across a safepoint.
• Add telemetry proving the existing workload publishes materially fewer batches, plus focused collection/root-survival coverage.
• Benchmark direct, shared 1/2/4/8, and independent-context behavior with exact checksums and bounded footprint; reject the change if lower lanes regress.

Acceptance

• Preserve exact object semantics, observable step/checkpoint order, GC safety, and allocation-failure behavior.
• Reduce shared object-batch publications by at least 8x on the focused allocation loop.
• Materially improve shared 4/8-lane wall time without regressing direct or independent-context results.
• Pass focused semantic/GC tests, full units, and TSan before publication.