wasm codegen: for-in/while loop bodies never execute in compiled programs (pre-existing, untested) #255

Summary

The wasm backend compiles loops but the loop body never runs in the produced module. Minimal repro:

```
fn main() -> Int {
let arr = [1, 2, 3, 4, 5];
let mut s = 0;
for x in arr { s += x; }
return s;
}
```

`affinescript compile` → wasm; `instance.exports.main()` returns 0 (expected 15). The same 0-iteration behaviour reproduces for while + index, and across element types ([Int], [String], [VNode], [(String,String)] — the tuple-list case additionally traps memory access out of bounds).

Pre-existing + untested

• Reproduces unchanged at 81a59bf (pre INT-01 test(xmod): INT-01 — prove + regression-lock cross-module wasm linking (Refs #178) #244) and at current main (d88770a) — not a regression, long-standing.
• Zero test coverage: tests/codegen/test_for_loop.affine exists but there is no test_for_loop.mjs, so tools/run_codegen_wasm_tests.sh compiles it and never executes/asserts it. Arrays + direct indexing (a[0]) work and are asserted (test_tuple_record_array → 81); no asserted fixture exercises a loop.

Impact

Blocks every list-processing wasm program. Directly blocks INT-08 (#183) runtime (the DOM reconciler compiles cleanly but cannot iterate children/attributes at runtime) and likely INT-07 (#182) TEA run loop. Source-to-source targets (Deno-ESM etc.) are unaffected.

Asks

1. Root-cause + fix the for-in/while lowering in lib/codegen.ml.
2. Add an asserting tests/codegen/test_for_loop.mjs (and a while one) so the gate catches this class permanently.

Surfaced by INT-08 (#183). Refs #183.