Perf: batch direct object-literal loop allocation between safepoints

Evidence

The July 14 publication leaves object_churn as the only direct JSC loss: 121.638 ms for zig-js versus 118.874 ms for JSC (2.3%). A fresh current-main ReleaseFast sample still places gc.allocObject / Heap.create / GcCellBacking.allocFn in the direct checkpoint-bounded quick loop.

The loop already allocates up to 17 objects at once when parallel_sync is enabled, because seventeen 61-step iterations can fit around the 1,024-step checkpoint boundary. The direct path uses the same safepoint budget but still performs one Heap.create per object. allocObjectBatch default-initializes every returned payload immediately, so tracing remains safe until the objects are consumed.

Scope

• use the existing checkpoint-bounded object batch in direct and shared modes
• preserve exact step accounting, checksum, fallback, and OOM-prefix behavior
• add focused telemetry proving direct GC contexts consume the batch path
• compare the exact pre-change and candidate runners with matching checksums
• retain only if the direct object-churn result improves; refresh README/report after material published changes

Parent: #97; matrix objective: #44.

Rejected after exact interleaved A/B on Apple M4 Max.

• baseline 044a386a: median 116.947 ms (21 samples, 116.244–128.744 ms)
• direct-batch candidate: median 130.064 ms (21 samples, 129.409–133.910 ms)
• change: +11.2% slower
• paired outcome: candidate won 0/21 samples
• checksum: 1030552128 for every baseline and candidate sample

Focused VM/shared/direct-GC correctness coverage passed, but the non-contended direct path is materially faster with one-cell allocation than createBatch. The source experiment was fully reverted and will not be landed. Follow-up optimization work remains tracked by parent #97.

Closing as a measured negative result; no source or benchmark documentation change is being pushed.