Allocation-free FastArray iteration with `op_iterator_close_check`

Component: JSC bytecode | 35637c6

op_iterator_open/op_iterator_next implement the generic JS iteration protocol; the existing FastArray path special-cases plain Arrays under arrayIteratorProtocolWatchpointSet, invalidated when Array.prototype[Symbol.iterator]/%ArrayIteratorPrototype%.next is replaced or a return appears on the prototype chain. This commit stops allocating a JSArrayIterator on every op_iterator_open for FastArray mode; iteration state (array + index) lives directly in the iterator/next/iterable bytecode operands via a sentinel, and a new op_iterator_close_check opcode lazily materializes a real JSArrayIterator only once the watchpoint is invalidated by close time.

Significance

for-of and array destructuring — among the hottest JS paths — lose their per-loop-open iterator allocation, but at the cost of reassigning existing operand meanings across LLInt/Baseline/DFG and through OSR.

Audit directions

The state machine must be reconstructed identically whether execution starts in the interpreter, tiers up mid-loop via OSR, or falls off the fast path — any divergence in how a tier reads/writes iterator/next/iterable is a type-confusion risk, since DFG treats these as typed values (ObjectUse checks conditionally elided on a hasSeenFastArray metadata bit). Narrow: audit each tier's handling of the sentinel-vs-materialized distinction at OSR entry/exit. Wider: any bytecode that repurposes operand slots as a cross-tier state machine shares this hazard. The tell: an ObjectUse elision keyed on a metadata bit set by a different tier.

---