CI: typed_shape_descriptors::bounded_integer_array_store_omits_layout_note_and_barrier red on main since #4957 (iota-fill idiom collapses the loop) #4985

cargo-test has been failing on every PR today (#4978, #4979, #4980, #4981 — all admin-merged through it):

thread 'bounded_integer_array_store_omits_layout_note_and_barrier' panicked at crates/perry-codegen/tests/typed_shape_descriptors.rs:430:5:
bounded numeric array store should route through the raw-f64 payload helper

Bisect

• 3fbeea978 (fix(hir): self-named native member base no longer OOM-loops codegen (#4908) #4955): passes
• 90bc7bc68 "Optimize numeric array raw payload helpers (Optimize numeric array raw payload helpers #4957)": fails

Confirmed locally at both commits with cargo test --release -p perry-codegen --test typed_shape_descriptors.

Why

#4957's loop-idiom recognizer in stmt/loops.rs collapses exactly the shape this test builds —

for (let i = 0; i < arr.length; i++) arr[i] = i;

— into a single js_array_fill_f64_iota_len_extend runtime call. The per-element store is never emitted, so all three assertions (js_array_numeric_set_f64_unboxed, js_typed_feedback_numeric_array_index_set_guard, js_typed_feedback_array_index_set_fallback_boxed) can't match. The test predates the recognizer and wasn't updated in #4957.

Suggested fix

Either:

1. Change the test body so it no longer matches the iota idiom (e.g. store i * 2 or a non-iota RHS) so it keeps covering the guarded per-element raw-f64 path, and add a separate test asserting the new js_array_fill_f64_iota_len_extend emission for the idiom; or
2. If the recognizer is meant to subsume this shape entirely, rewrite the assertions to the fill helper.

Option 1 preserves coverage of the guard/fallback machinery, which now has no test exercising it.