Bound resource use when iterating ranges

[ianks]

The CI repairs landed in #2118. Declarative range behavior and resource-limit coverage landed in Shopify/liquid-spec#165; this PR pins its merged revision and retains Ruby-only allocation, counter, repeated-render, and custom-Range checks.

for and tablerow can materialize an entire range before resource limits run. This replaces that allocation with a small integer-range window: length, offsets, and reversal use arithmetic, and values are generated as the loop visits them.

Each visited range item consumes render score before entering the body, including empty bodies. Early break only pays for the values visited; loop metadata and offset:continue retain the full selected length. tablerow also checks its generated HTML incrementally, including captured output and break paths.

Tight render-score budgets may now stop range loops earlier. Output-length limits still bound bytes, not CPU work in output-free loops. Non-range collections keep the existing slicing and load_slice behavior.

Validation and cost

All lax/strict/strict2 tests, four liquid-spec adapters, RuboCop, and the memory-profile task pass locally. Each adapter passes 2,845 liquid-spec cases, including the 10 staged range resource-limit cases and 9 imported compatibility cases. Regression tests guard both historical materialization paths, so they fail safely against the old code rather than attempting huge allocations.

Five paired Ruby 4.0.6 benchmark runs measured about 2% overhead for small for range loops and 6% for tablerow range loops with the additional checks. The range window stayed at 80 bytes for cardinalities of 10, one million, and one billion; output storage is separate.