Math.sumPrecise: enforce the iterator element-count bound

Parents: #475, #493 Related: #750

Problem

ECMA-262 requires Math.sumPrecise to reject an iterator once its processed element count reaches 2^53 - 1. Before consuming that next value, it must create a RangeError and perform IteratorClose. The current implementation increments an unbounded usize counter and has no specified limit, so it omits both the security/performance bound and the required close behavior.

Scope

• Enforce the exact 2^53 - 1 bound before accepting another Number.
• Close the iterator with the RangeError completion.
• Preserve the original RangeError when return() throws or otherwise completes abruptly.
• Add a narrow internal test seam for the otherwise impractical boundary without changing the public JavaScript API or production limit.

No-workaround rules

• No smaller production cap, iteration timeout, allocation heuristic, source rewriting, skipped IteratorClose, or replacement error from return().
• No stack, queue, job, Promise, Worker, or Map/Set iterator implementation changes.

Acceptance

• Production uses the exact 2^53 - 1 element bound.
• The boundary path performs IteratorClose and preserves RangeError precedence.
• Focused units and the complete Test262 Math.sumPrecise subtree pass with exact nonzero accounting.
• Full integration gates pass with 0 unrelated Test262 flips.

Implementation progress: production now uses the exact 2^53 - 1 u64 bound; the check occurs after IteratorStepValue but before Number validation; RangeError is created before IteratorClose and retained over a throwing return(). A test-only native supplies limit 2 inside a fresh context without changing the JS API or production limit. Focused evidence: exact boundary regression 1/1 passed, complete Math.sumPrecise filter 3/3 passed, 0 leaked. Candidate Test262 is queued behind an unrelated active Zig build.

Landed on main as 25b8d23e. Exact-parent Test262 evidence for test/built-ins/Math/sumPrecise: 10 pass -> 10 pass, 0 fail, 0 flips. Focused Math.sumPrecise units: 3/3 passed, 0 leaked. Leaving the issue open for the new main CI matrix.

Main integration run: CI 32804791010.

Follow-up proof comment landed in 65ea35fd: the exact cardinality bound keeps the worst-case scaled magnitude below 2^2151, leaving more than 150 signed-magnitude head bits in the 2,304-bit accumulator. Comment-only; 0 Test262 flips.

Final descendant integration run after the proof-only follow-up: CI 32804870572.

Descendant CI 32804870572 completed 51 jobs successfully, including all unit/TSan unit shards, Test262 parallel, every TSan no-GIL corpus shard, Wasm smokes, docs, private ABI, and lifecycle fuzzing. Its sole functional failure is the separately tracked #722 mc-lock-stop-vs-park assertion; the benchmark harness was canceled only when the next direct-main #752 push superseded the run. The full-integration acceptance box therefore remains deliberately unchecked pending a descendant matrix without #722 red.

Full integration remains deliberately open. CI 32890815195 completed 52 required jobs successfully (including all unit, TSan, Test262, no-GIL corpus, threadfuzz, docs, Wasm, and ABI legs); the sole remaining benchmark-comparison-harness leg was automatically cancelled at the matrix's exact 60-minute limit, with no test failure reported. The causal CI-duration defect is tracked in #765. I am not treating a cancelled leg as a pass.

Full integration is now proven by main CI run 32923883777: all 53 required jobs passed, the sole nightly-only job was skipped as configured, and 0 jobs failed or were cancelled. This includes all unit/TSan, Test262, threading/no-GIL, fuzz, Wasm, docs, ABI, and benchmark harness gates. The implementation remains 25b8d23e, with exact-parent Math.sumPrecise Test262 evidence 10/10 -> 10/10 and 0 flips.