Optimization: eliminate runtime bounds guard for provably in-bounds dynamic indices

[0xGeorgii]

Summary

Eliminate the runtime array bounds guard for dynamic indices that are provably in bounds, recovering performance/size while keeping safety.

Background

#164 emits a runtime guard (index >= length -> unreachable) before every dynamic-index array access in Compile-mode builds (Debug and Release). Many of those indices are statically known to be in range, so the guard is dead weight there.

Proposal

Add a lightweight range/dominator analysis that proves 0 <= i < length for a dynamic access and lets codegen drop the guard for that specific access. Target the common, decidable patterns:

• Loop-bounded indices: loop (i < len) { arr[i]; ... } — the loop condition bounds i in the body.
• Guard-dominated indices: an access dominated by if i < N { ... arr[i] ... } with no reassignment of i between guard and use.
• Constant-propagated indices that resolve to an in-range literal (already covered statically by A037 for literals).

Where the analysis cannot prove in-bounds, the runtime guard stays (safe default). False negatives (keep the guard) are acceptable; false positives (drop a needed guard) are not.

Relationship

• Optimization layered on Array Bounds Checking #164's runtime guard.
• Distinct from Static rule: require a dominating in-bounds guard before dynamic array indexing #212: Static rule: require a dominating in-bounds guard before dynamic array indexing #212 forces the programmer to write a dominating guard (and makes OOB recoverable); this issue automatically proves in-bounds and removes the runtime check. If Static rule: require a dominating in-bounds guard before dynamic array indexing #212 lands, a programmer-written if i < N guard becomes exactly the evidence this analysis would consume to elide the trap.
• Tracked as Array Bounds Checking #164 Deferred Work ("range-based static elimination").

Future work.