i32 fast-path locals and loop counters silently wrap at 2^31

[proggeramlug]

Severity: P1 (silent data corruption; potential infinite loop)
Found by: audit fable-audit-perry-2.md, confirmed by probe.

What

Locals and loop counters that codegen classifies into i32 slots do a plain add i32 with no overflow handling, so they wrap at 2³¹ instead of promoting to double.

let big = 2147483640;
for (let k = 0; k < 10; k++) big++;
console.log(big);           // node: 2147483650   perry: -2147483646

// runtime-bound loop crossing 2^31:
for (let i = 2147483640; i < lim; i++) { ... }   // lim = 2147483653
// node: 13 iterations      perry: i wraps negative past 2^31 → spins (only a safety break stopped the probe)

Why

crates/perry-codegen/src/expr/literals_vars.rs:796 (let new_i32 = blk.add(I32, &old_i32, delta);) and the raw add(I32, …) sites in expr/i32_fast_path.rs:635,994 and stmt/loops.rs:912,1980 emit unchecked i32 adds. The range guards validate the initializer, not that increments stay below 2³¹ when the bound is a runtime value.

Fix

Emit llvm.sadd.with.overflow.i32 on the update path and bail to the double representation on overflow, or gate the i32 slot on a range_facts proof that the loop/accumulator bound is provably < 2^31.

Confidence: high (probe + source).

[proggeramlug]

Root-cause refinement (from reading the codegen): the fix is not an overflow-checked add on the update path. This is the Issue #48 optimization — an int32-stable local is represented as an i32 SSA value, and every LocalGet reads the i32 slot and sitofps it to double (crates/perry-codegen/src/expr/literals_vars.rs:459-467), while the parallel double slot is maintained only for closures/escape sites and then DCE'd. So console.log(big) reads the wrapped i32, not the (correct, non-wrapping) double.

The wrap is therefore intrinsic to the representation, and the real fix is in the classification that admits a local into integer_locals / i32_counter_slots: it must require a range proof that the value stays in [-2^31, 2^31) (a constant loop bound < 2^31, or provably-non-overflowing integer ops). Locals that can exceed i32 must stay double-represented. An overflow check on the update alone can't help, because the read path is statically bound to the i32 slot.

This is an optimization-correctness change (touches the hot integer-loop path + gated by compiler-output-regression), so it wants dedicated design + benchmarking rather than a drive-by patch.

[proggeramlug]

Both repros in this issue are fixed on main — closing.

repro	fix
1. Bare accumulator (let big = 2147483640; big++) silently wraps	#6258 — x++/x-- disqualifies the i32 fast path
2. for counter with a runtime bound crossing 2^31 wraps to INT32_MIN and spins forever	#6318 — the dynamic-bound counter must be proved to stay in i32; otherwise it gets a loop-private counter that never enters the shared slot map

Re-verified on current main: byte-identical to node --experimental-strip-types, and the dynamic-bound loop terminates.

Two further faces of the same i32 blind spot were found while fixing these and are tracked separately, so this issue isn't the right home for them:

• i32 fast-path: copying a local seeded with a >2^31 integer literal wraps (third face of #6072) #6319 — copying a local seeded with a >2^31 integer literal wraps (let x = 3000000000; y = x → -1294967296). Fix in flight (fix(codegen): an integer literal past 2^31 must not seed the i32 fast path (#6319) #6340). It also fixes an unreported case: n > 2147483647 was returning false.
• i32 fast path: copying a local whose value came from an arithmetic chain past 2^31 wraps (fourth face of #6072) #6339 — copying a local whose value came from an arithmetic chain past 2^31. Different root: is_strictly_i32_bounded_expr's LocalGet arm reads integer_locals, which by design admits overflowing Add/Sub/Mul. Closing it means turning the strict set into a greatest fixpoint, which touches the set that recovers image_conv's FNV accumulator — so it needs its own gate run.