…ual of #514)

Closes #535. v0.0.121 fixed nested closures and primitive/ADT captures;
this release closes the residual pair-type subset where String / Array<T>
captures silently dropped their len field.

## Root cause

`vera/wasm/closures.py::_walk_free_vars` resolved each capture's wasm
type via `_type_name_to_wasm`, which collapses every composite type to
a single "i32" (handler call sites depend on this single-slot return).
For pair-typed values, the value lives on the stack as TWO i32 slots
(ptr + len). The pre-fix path:

  - allocated 4 bytes per pair capture instead of 8
  - stored only the ptr (the value at `local.get {local_idx}`)
  - read back only the ptr in the lifted body
  - len was read as garbage from adjacent struct memory (typically zero)

Result: `array_length(@array<Int>.0)` and `string_length(@String.0)` of
captured pairs always returned 0; any operation on the captured value
saw it as empty.

## Fix (3 sites in lockstep)

1. `vera/wasm/closures.py::_walk_free_vars` — when the resolved type is
   String / Array / Array<...>, override the wasm tag to "i32_pair".
   `_type_name_to_wasm` is left alone so handler call sites
   (handle_state, handle_exn) still get the single-slot return they
   expect.

2. `vera/wasm/closures.py::_translate_anon_fn` — pair-aware closure
   struct layout (8 bytes, 4-aligned, two consecutive i32 fields) and
   store (i32.store offset=N for ptr, i32.store offset=N+4 for len,
   reading from `local_idx` and `local_idx + 1` respectively).

3. `vera/codegen/closures.py::_compile_lifted_closure` — mirror the
   layout on read. Allocate two consecutive i32 locals (ptr, len),
   load both halves from the env struct, and push only the ptr into
   the SlotEnv (matching the let-binding and parameter convention).
   Sanity assert that the two locals are consecutive.

4. GC handling: extend the captured-pointer shadow_push loop to handle
   pair captures (push the ptr local; the len is a byte count, not a
   heap pointer).

## Tests

`TestPairCapture535` (5 cases):

  - test_array_capture_length_in_closure (returns 21 not 0)
  - test_string_capture_length_in_closure (returns 15 not 0)
  - test_adt_capture_still_works (regression pin: 126)
  - test_primitive_capture_still_works (regression pin: 21)
  - test_mixed_pair_and_primitive_capture (layout-order exercise: 312)

3,680 -> 3,685 tests. mypy clean, 82 conformance programs pass,
33 examples pass.

Co-Authored-By: Claude <noreply@anthropic.invalid>

CI lint job's "Security lint (ruff S rules)" step failed because
vera/codegen/closures.py used a bare assert for the
consecutive-locals invariant. Ruff S101 forbids assert in
production code since it gets stripped under python -O.

Converted to an explicit if ... raise RuntimeError so the check
survives optimization. Behavior is unchanged in normal runs.

Co-Authored-By: Claude <noreply@anthropic.invalid>

Inline (1):
  1. vera/codegen/closures.py 308-316 — capture-root GC pushes were
     emitted into gc_prologue (before load_instrs), but the env-loads
     hadn't run yet at that point so cap_local still held the default
     0; gc_shadow_push snapshots the local's CURRENT value, so a zero
     was being written to the shadow stack instead of the loaded ptr.
     Captured heap pointers reachable only through the closure could
     be GC'd while in use.

     Pre-existing for i32 captures (PR #569 just extended the
     pattern to i32_pair). Fix: split the prologue into two phases —
     gc_prologue (sp save + param pushes, runs before load_instrs)
     and gc_capture_pushes (capture roots, runs AFTER load_instrs).
     Assembly order now: locals decl, sp save + param pushes, env
     loads, capture roots, body, epilogue.

Outside-of-diff (1):
  2. tests/test_codegen.py — added two edge-case tests:
       test_empty_string_capture_in_closure (empty String captured)
       test_empty_array_capture_in_closure (empty Array<Int> captured)
     Both assert _run(src) == 0. Pin that the post-fix path correctly
     preserves a zero-length pair capture (rather than reading
     garbage from an unallocated len slot in the closure struct).

Test count: 3,685 → 3,687.
ruff S clean, mypy clean, 82 conformance programs pass, 33 examples pass.

Co-Authored-By: Claude <noreply@anthropic.invalid>

Inline (1):
  tests/test_codegen.py 14890-15047 — add tests that exercise the
  round-1 GC-ordering fix (gc_capture_pushes after load_instrs)
  under in-closure allocation pressure.

Two tests added under TestPairCapture535:

  test_gc_pressure_pair_capture
    Captures @array<Int> = array_range(0, 7) (length 7).  Inside the
    closure body, allocates 3 × array_range(0, 500) = ~12 KB of temp
    arrays BEFORE reading array_length(@array<Int>.3) (.3 because
    the captured array sits at outer-scope index 3, after the three
    inner let-bindings at 0, 1, 2).  Asserts folded sum = 21 (3 × 7).

  test_gc_pressure_string_capture
    Same shape with @string = "hello"; asserts 15 (3 × 5).

If a future change re-broke the GC ordering (capture pushes back
in gc_prologue before load_instrs), these tests would catch it
when in-body allocations cross the GC threshold and a $gc_collect
sweeps the captured pair as unreachable.

Test count: 3,687 → 3,689.
ruff S clean, mypy clean, full pytest passes.

Co-Authored-By: Claude <noreply@anthropic.invalid>