JSON.parse: reuse exact small-object shapes across private parses

Parent: #473

Repeated JSON.parse calls rebuild the same small ordinary object shapes through generic transition lookup and per-property publication even though parsed objects remain private until the parse succeeds. Exact attribution on the current pushed #1011 baseline records 1,984,837 shape-transition requests for each frozen representative parse row.

A bounded invocation-local prototype buffers at most Object.inline_slot_capacity fields, byte-verifies a previously prepared immutable shape chain, and bulk-initializes only a fresh private object. Reordered keys, duplicates, canonical index keys, a fifth field, or any shape mismatch fall back to the unchanged CreateDataProperty path. The cache is lazy and per Interpreter, so it crosses neither realms nor concurrent workers.

Measured prototype evidence against pushed 3abc2fc:

• representative_json: 1,984,837 -> 4,892 shape requests, exact checksum/cell/allocation/collection counts; seven-pair retired instructions 0.97806x.
• representative_json_variant: 1,984,837 -> 4,892 shape requests, exact checksum/cell/allocation/collection counts; seven-pair retired instructions 0.97500x.
• escaped-string, depth, and shallow controls remain within 0.19% retired instructions.
• reviver attribution is causally unchanged; its first seven-pair timing set is noisy, so a dedicated 15-pair control rerun remains required before landing.

Two alternatives were measured and rejected without commits: a realm-owner atomic cache caused a stable escaped-string timing regression despite neutral instructions, and stateless transition-chain replay regressed the owned rows by 0.66-1.06% instructions.

Definition of done:

• dedicated control rerun confirms no hidden regression
• exact reuse plus duplicate/index/wide/NUL fallback unit coverage
• allocation-failure sweep and deep-input behavior
• moving-GC plus no-GIL/TSan coverage
• JSON test262 and required-VM agreement
• final seven-pair checksums/counters from the exact landed binary
• small conventional commit pushed directly to main under the configured user, no trailers

Dedicated 15-pair alternating controls resolve the noisy seven-pair sample without changing the candidate: reviver_source is 0.99887x retired instructions, 1.00058x cycles, and 1.00500x measured CPU (parent CPU RSD 14.86%, candidate 3.39%); escaped_strings is 1.00028x instructions, 1.00458x cycles, and 1.00430x CPU. All 60 runs kept exact checksums and nominal->nominal thermal state. The control gate is accepted; focused semantic/GC/TSan gates are now running under the shared 3 GB machine lock.

Landed on main as b0f4b41.

Exact final artifacts:

• test262 SHA-256: 130d1a2b39378835cdee8ef8189dfd3bb77002d6f8f9634502fdcab5812d76bd
• benchmark SHA-256: 5dfe3ded33a5c1f4a8d7aa09f0332d1378e59459bd9b987f5cd9c1d8290d2e60

Final attribution against pushed parent 3abc2fc:

• both frozen ordinary rows: shape requests 1,984,837 -> 4,892 (-99.75%)
• checksums, backing allocations, GC cell allocations, and collection counts are exact
• variant and reviver retain one fewer arena backing release due to sidecar packing; peak RSS remains within 0.17%
• reviver and escaped-string causal counters are otherwise unchanged

Seven exact-final alternating pairs, all nominal thermal and exact checksums:

• representative_json: instructions 0.97548x, CPU 0.96013x, wall 0.96034x, cycles 0.95329x
• representative_json_variant: instructions 0.97308x, CPU 0.94895x, wall 0.94725x, cycles 0.95260x
• escaped/depth/shallow controls: 1.00019x, 1.00111x, 1.00077x instructions
• reviver control: 0.99670x instructions; its dedicated 15-pair confirmation was 0.99887x instructions and 1.00058x cycles

Gates:

• JSON parser/OOM unit family: 10/10
• no-GIL required-VM + parallel GC under TSan: 2/2
• moving-GC reviver suite: 2/2
• test262 JSON: 165 pass / 0 fail
• tree vs required VM: 165 agree / 0 diverge
• 50,000-level array/object rejection plus 96-level acceptance: OK true in tree and VM
• maximum observed build/test footprint: 2.186 GB under the 3 GB guard

The commit author and committer are both glennmichael123 <gtorregosa@gmail.com> and the message has no trailers.