Perf: reuse the ordinary-object prototype in fixed-shape allocation loops

Problem

The fixed-shape object-allocation quick loop still calls Interpreter.newObject() for every fresh object. That helper resolves %Object.prototype% by walking to the realm environment and taking its binding lock on every allocation, even though the intrinsic identity is cached and immutable after bootstrap.

A current symbolized object_churn profile on main shows Interpreter.objectProto / TLS and binding-lock work in the remaining hot path. This is general fixed-shape allocation overhead, not workload source specialization.

Parent: #62

Proposed slice

• Resolve the ordinary-object intrinsic prototype once when entering a validated fixed-shape allocation loop.
• Add a general object-allocation helper that accepts an already-resolved prototype.
• Preserve bootstrap/null-prototype semantics and the ordinary newObject() path.
• Keep the quick path disabled for shared/escaped frames exactly as today.

Acceptance criteria

• Focused VM tests prove the quick path still executes and preserves exact step accounting/checksums.
• A targeted test proves the pre-resolved helper installs the supplied prototype and does not re-read a shadowed global Object binding.
• Order-balanced fresh-process A/B on the exact object_churn checksum shows a repeatable improvement; reject and revert if it does not.
• Full zig-js unit and benchmark-harness suites pass before merge.
• Commit references this issue and is pushed as a small conventional commit.

Rejected and fully reverted after a clean detached-baseline A/B. Seven order-balanced fresh-process pairs used three timed samples per process at 100 jobs; all 42 checksums were exactly 1030552128. Baseline median-of-process-medians was 242.461416 ms and the candidate was 244.943375 ms, a 1.0237% elapsed regression. The candidate won only 1/7 pairs. The heavily loaded host makes absolute JSC publication invalid, but the paired result is consistent enough to reject this slice. No source commit was created; #62 remains the parent for the next profile-driven allocation/sweep optimization.