Improve BP-OSD distance certification reliability in the live evaluation loop

Problem

The evolutionary campaigns' live fitness signal for distance is BP-OSD (evaluation/distance.py, and for non-CSS evaluation/distance_bposd_noncss.py), gated by a purely empirical heuristic in evaluation/evaluator.py:

DISTANCE_TRUST_RATIO = 1.3    # d/sqrt(n) <= this: fully trust BP-OSD's d
DISTANCE_UNTRUST_RATIO = 2.0  # d/sqrt(n) >= this: discard BP-OSD's d, use k/n only

Per the module's own docstring (evaluation/evaluator.py:69-85), these thresholds are set from a handful of manually observed data points — four known-good ratios (0.71-1.26) and a few degenerate ones (2.5-4.0) — with an explicitly untested gap in (1.26, 2.5) where "no observed code" has landed. evolve/openevolve_evaluator.py then linearly interpolates a "credible FOM" between the two thresholds (TRUST_FULL/TRUST_NONE, around line 569) to shape the reward the LLM mutator sees during search. That reward is therefore built on a heuristic that is, by its own documentation, unvalidated in the middle of its range — exactly where a genuinely good high-rate candidate is most likely to land.

This isn't a theoretical concern; it's the documented cause of real, large errors:

• CLAUDE.md's own "Known issues" section: "BP-OSD overestimates distance by up to 12x for high-rate codes" and "A single BP-OSD run is unreliable — estimates can range from 6 to 18 across independent batches on the same code." Even the publication-grade protocol (150,000 trials: 3 decoder configs x 10 batches x 5,000 trials each, tests/soak_test.py) needed MILP to catch that 8 of 9 codes were still overestimated after tightening, and some by up to 12x even at that trial count.
• Non-CSS codes have a distinct, sharper failure mode: naive/random-syndrome BP-OSD sampling misses the achievable syndrome subspace (probability as low as 1/4096), so decoderDist-style BP-OSD is "near-useless" there — an independent cross-check (Webster codedistance, arXiv:2603.22532; merged as evaluation/distance_webster.py in PR #3) measured it returning d=126 on a code whose true distance is 20. evaluation/distance_bposd_noncss.py::_compute_achievable_basis fixes this for our own BP-OSD path, but it's a targeted patch rather than something that changes the trust-ratio heuristic's underlying assumptions.
• The same cross-check found a cheaper alternative, QDistEvol, closed the gap on 17/17 of the worst BP-OSD-overestimate CSS codes (reaching the MILP-verified truth) and even beat our own best-known incumbent on one PBB code (24 -> 20), while decoderDist (BP-OSD) closed 9/9 CSS but 0/8 non-CSS cases in the same comparison. That data currently lives only in the post-hoc audit pass over the finished catalog, not in the live loop.

The net effect: the fitness signal the LLM mutator actually optimizes against during a campaign is noisier and more biased than the numbers the project ultimately publishes, because the expensive corrections (MILP via evaluate_candidate_milp/evaluate_stage2_milp, the Webster cross-check, QDistEvol) are applied after the campaign, not during it. evaluate_candidate_milp (evaluation/evaluator.py:343) and evaluate_stage2_milp (evolve/openevolve_evaluator.py:725) exist and work, but MILP-in-the-loop is opt-in (use_milp=False by default) and expensive, so default campaigns run on the heuristic-gated BP-OSD signal throughout.

Ask

1. Replace or tighten the DISTANCE_TRUST_RATIO/DISTANCE_UNTRUST_RATIO heuristic with something grounded in more than a handful of manually-observed ratios — e.g. backfill the trust curve using the now much larger MILP-verified catalog (results/ilp_catalog.json, results/campaign7_publication_merged.jsonl) instead of the original ~4-point empirical fit, and close or characterize the untested (1.26, 2.5) gap rather than interpolating blindly across it.
2. Evaluate promoting a cheaper-but-more-reliable method (e.g. QDistEvol, per the 17/17 result above) into the live per-candidate loop, at least for candidates that clear the preliminary FOM threshold, rather than relying solely on BP-OSD for the reward signal the mutator actually sees.
3. Make the non-CSS achievable-syndrome sampling fix (_compute_achievable_basis) and the multi-decoder/multi-batch protocol (currently manually invoked via tests/soak_test.py-style scripts) part of the default evaluation path rather than something applied only in dedicated verification passes, so campaign-time and publication-time distance estimates aren't governed by different reliability standards.
4. Document, in evaluation/evaluator.py or CLAUDE.md, how big the divergence between in-loop (BP-OSD-gated) FOM and final certified FOM has been historically, so future campaign designers know how much to discount live rankings.

Related but separate

Open PR #2 on this repo ("Certify exact distances for six previously unresolved PBB codes") is about closing d_is_exact: false gaps in the published catalog after the fact — consistent with the pattern above, where exactness/certification work happens downstream of the campaign rather than during it. Flagging it as related context, not as something this issue depends on resolving.

Read evaluation/evaluator.py, evaluation/distance.py, evaluation/distance_bposd_noncss.py, and evolve/openevolve_evaluator.py to trace the live BP-OSD trust curve and FOM. Compare the heuristic against results/ilp_catalog.json and results/campaign7_publication_merged.jsonl, using tests/soak_test.py as the reference for multi-batch verification. Done means the live and final evaluation paths use a justified reliability protocol and document their historical divergence.