SIGSEGV after several frozen for-of-head rejections, then a for-of head on an UNfrozen object #9460

A .cts that runs several for (o.x of …) cases against frozen objects and then the same shape against an unfrozen object segfaults.

It does not reproduce in isolation — the preceding throwing cases are required — which points at state corruption on the throw path rather than a fault in the final statement.

Repro kept at scratchpad/repro/r_lanes.cts from the #9422/#9423 investigation.

Likely connection

The throwing path here is the over-throw described in the companion issue: for (o.x of …) on a frozen object raises a TypeError that node does not raise, via js_typed_feedback_object_set_field_by_name on the Expr::PropertySet lane, which has no strictness field. So these are throws that should not be happening at all, and the crash is what happens after several of them.

Two candidate mechanisms, both worth checking before assuming:

1. The exception transport leaves the typed-feedback or IC state inconsistent when it unwinds out of a store site — this touches the setjmp/longjmp machinery reworked in fix(runtime): no Rust frame is ever a longjmp target — cc --help segfault fixed, parity gate back online (#9305) #9323 (perry_sjlj_try), where LLVM slot colouring across returns_twice has bitten before.
2. A rooting hole on the throw path, in the family of cc auth-error path: Cannot read properties of undefined (reading 'def') where node reports Not logged in #9417/fix(runtime): an accessor call must not corrupt the caller's this (found while diagnosing #9417) #9444/Sweep: ~20 unrooted js_implicit_this_set(prev) save/restores hold a bare local across allocating user code #9445 — a value held across the unwind that the collector does not see.

PERRY_GC_PROTECT_FROMSPACE=1 distinguishes them quickly: if it faults on a retired address, it is (2).

Note the companion fix may make this unreproducible without fixing it — if for (o.x of …) stops throwing in sloppy code, the sequence that triggers the crash disappears. That would hide a real defect rather than fix it, so this needs a repro that throws legitimately (the same shapes under "use strict", where the TypeError is correct) before the over-throw is fixed.

Found while fixing #9422/#9423.