Perf: defer remaining object-loop frame writes

Parent: #62 Follows: #91

Problem

After #91, the isolated fixed-shape object-allocation loop still writes index, displaced, value, and fresh into Frame.slots on every fused iteration. During a successful quick batch these locals are not observed until batch exit:

• the current displaced object remains rooted by the array until replacement
• the fresh object is rooted by the array immediately after replacement
• the next iteration overwrites the old displaced local before allocating again
• the quick path already rejects escaped frames and synchronized execution

Allocation and restricted-receiver errors must still expose bytecode-exact current/previous locals.

Proposed change

• retain the last completed iteration values in native locals
• publish the four frame slots once on normal quick-batch exit
• on allocation failure, publish the current partial index/displaced/value plus the last completed fresh value
• on restricted-receiver failure, publish the current partial index/displaced/value/fresh exactly as today
• preserve step accounting, GC rooting, guarded fallback, and checksum behavior

Acceptance

• existing fixed-shape allocation, multi-checkpoint, nursery-retention, observable fallback, and restricted-receiver tests pass with zero leaks
• exact checksum remains 1030552128
• exact-parent alternating object_churn A/B reproduces a material win
• batch full validation only if retained
• revert and close as not planned if neutral or slower

Experimented locally and rejected; no commit was created.

Implementation:

• retained the last completed index, displaced, value, and fresh values in native locals
• published those four frame slots once at normal quick-batch exit
• preserved current partial locals on allocation and restricted-receiver errors
• retained #91 numeric frame-write deferral unchanged

Correctness:

• fixed-shape allocation filter: 3/3 passed, zero leaks
• quick-object replacement filter: 3/3 passed, zero leaks

Exact-parent A/B against 94078ba7:

• 14 alternating process pairs
• 3 samples per process
• exact checksum 1030552128 throughout
• candidate wins: 8/14
• median of process medians: parent 214.754 ms, candidate 212.482 ms
• paired median change: approximately -1.06%
• first batch: 4/7 wins
• confirmation batch: 4/7 wins

The host produced large outliers in both directions, and neither batch showed a convincing win rate. The approximately one-percent median signal does not justify four extra tracked native values plus more complex allocation-error publication. The source was fully reverted and the worktree is clean.