opt=2: fail closed when a variant's accuracy cannot be computed

[axiom-of-choice]

The small independent PR you asked for in #153. Not the fix for that issue (that is #156, on the opt=1 path); this is the opt=2 hardening you called merge-worthy on its own.

The hole

_optimize.measure gated variants with:

if relerr > tol: return float("inf"), None

Every comparison with nan is False, so a variant whose error could not be computed was accepted rather than rejected. not (relerr <= tol) rejects nan and inf while leaving the inclusive boundary at tol exactly as it was.

One line, plus a comment recording why the form matters.

Why it is worth landing anyway

It does not change the #153 repro, and I want to be clear about that: opt=1 returns from _compile_opt before reaching this gate, so this line was never on that path. What it does protect is the opt=2/tune path against future lossy variants. Any variant that saturates, produces a shape mismatch upstream of the compare, or otherwise yields an uncomputable error currently rides through on a nan. int4-LUT and sparse are exactly the sort of additions that would trip it.

Verification

Check	Result
tests/test_variant_gate_failclosed.py	5 passed, build-level so they run in CI without an ANE
tests/test_tune_guards.py	9 passed
tests/run_corpus.py	GATE: GREEN, 90/90
ruff / pre-commit	clean

The tests cover nan rejected, inf rejected (computed from a real saturated-vs-finite pair, so the inf is produced rather than asserted), within-tolerance still accepted including the boundary at tol, and above-tolerance still rejected.

One of them pins the source form:

assert "not (relerr <= tol)" in src, "the accuracy gate must reject nan, not just large errors"

That is deliberate. The failure mode here is a plausible-looking edit back to relerr > tol, which no value-based test can catch once the gate stops being reachable with a nan in a normal run. Verified it fails on main and passes here. Happy to drop it if pinning source text is not to your taste; the other four stand on their own.

[sbryngelson]

Merged -- thanks. This closes a real hole: a nan relerr in measure() (_optimize.py:336) was silently accepted (nan > tol is False), and not (relerr <= tol) correctly rejects it. The source-form pin test is a nice touch.

One follow-up worth a look, since your #153 root-cause pointed at a different function. The nan you originally traced is in _measure_with_ref (_optimize.py:628 sets relerr = float("nan") when there's no usable reference), and that value flows into tune_precision, not measure(). There it hits r["relerr"] <= target_error (:697, which nan correctly fails) but then the fallbacks min(usable, key=lambda r: r["relerr"]) (:703/709/714) -- and min with a nan key sorts unpredictably, so an unusable variant could still get chosen there. Worth confirming whether that path also needs a fail-closed guard (drop rows with non-finite relerr before the min), or whether measure() is the gate that actually governs the opt=2/tune() route. Not blocking anything -- just flagging that #157 may be one of two, since it patches measure() and the analysis named _measure_with_ref.