fix(helpers): OFFSET/_dynRange answer #REF! (NaN) past sheet bounds — the mid-pass OOM root

[ebootheee]

What

The instrumented canonical A-1 run pinned the mid-pass OOM class: heap steady at 6.5GB through pass 4, death mid-pass-5 needing >13GB in one spike — an allocation proportional to a cell VALUE, fatal at any heap cap (identical ~56-min deaths under 12GB and 20GB).

_offsetAddr / _offset had no upper bounds: a displacement (or OFFSET height/width) fed by a poisoned/oscillating cell (~1e7 scale — the observed pass-4 maxDelta magnitude) produced addresses like row 20,000,000, and _dynRange/ctx.range materialized the rectangle — billions of cells. Past Excel's hard sheet bounds (1,048,576 × 16,384) Excel itself answers #REF!; the helpers now answer honest NaN there. Pre-fix, scalar OFFSET returned a silent 0 for an out-of-bounds read, and SUM over an out-of-bounds computed-endpoint range returned a confident finite number.

Also: cluster-child telemetry now names the max-delta cell, so the e7 oscillation is attributable on the next run.

Diagnosis context (posted to #33 as a correction)

• The probe's "2 passes, converged" was stride-20 sampling luck — the engine-mirrored full surface oscillates at e7 scale and is NOT settling.
• GPP Promote!C465 (persistent non-finite) is the workbook's own #DIV/0! (0/0, absent from GT) — our NaN is correct.
• Next session: identify the oscillating cell(s) via the new telemetry.

Tests

test-offset-ref-bounds.mjs — 7 asserts, negative-controlled via stash + rebuild: red pre-fix with exactly the predicted silent values (0, 6); in-bounds OFFSET/computed-endpoint shapes byte-unchanged. Full npm test green on this tree.

🤖 Generated with Claude Code