JSON.stringify: keep bounded key snapshots off the heap

Parent: #473

#993 bounded ordinary-object key snapshots with an invocation-scoped arena, but each small JSON.stringify still obtains three backing blocks from the precise heap. A stack-first child allocator with exact heap fallback keeps ordinary small snapshots local while preserving unbounded object support and the same arena lifetime.

Executed exact-parent evidence on real zig-gc, stripped ReleaseFast, frozen representative_json rows (2,200 jobs x 90 round trips):

• checksum: 324952086 on parent and candidate, base and variant
• backing allocations: 1,595,004 -> 1,001,004 on both rows (-594,000, exactly three per stringify)
• backing requested bytes: 582,274,972 -> 114,276,880 base (-467,998,092)
• backing requested bytes: 582,348,880 -> 114,227,896 variant (-468,120,984)
• retained backing, GC cells, shape transitions, and property-lock counts remain effectively unchanged
• one diagnostic CPU pass: base 581.941 ms -> 560.533 ms; variant 571.992 ms -> 535.269 ms

A 2 KiB prototype was executed and rejected: it removed allocator calls but spilled into an oversized fallback block, increasing requested bytes by exactly 996 per stringify. The 4 KiB reserve absorbs the measured small-object working set; larger/adversarial snapshots use the original precise-heap allocator through the fallback.

Definition of done:

• direct stack/fallback ownership test, including heap spill and deinit
• JSON OOM, Unicode, deep, callback, proxy, GC, and no-GIL coverage
• pinned Test262 JSON and forced VM agreement clean
• no-GIL TSan witness clean
• exact-parent frozen checksums and counters recorded
• clean-host seven-sample publication under #473 before closing

Landed and pushed to main as 15d8fbb4.\n\nQualification:\n\n- direct stack-to-heap spill/deinit coverage passes\n- focused JSON/OOM/Unicode/deep/proxy/GC tests: 27 passed\n- Test262 test/built-ins/JSON: 165 passed, 0 failed\n- forced VM agreement: 165 agree, 0 diverge\n- no-GIL TSan witness: 2 passed\n- frozen full checksum: 324952086 on parent/candidate, base/variant\n- exact reduction: 594,000 backing allocations on each row\n- requested bytes: -467,998,092 base; -468,120,984 variant\n\nLeaving this open only for the clean-host seven-sample publication required by #473. No wall-time claim is being published from the contaminated host.