GeezerVison

The overnight matrix hit a conda solver failure on the bottom rung:
the picker drew numpy 1.25 with numba 0.57, and conda-forge numba 0.57
requires numpy <1.25, so the environment could not solve and the job
died before running anything. The picker's constraints covered numba's
numpy 2.x boundaries but not this 1.x-era ceiling.

Bump numba 0.57 to 0.58 whenever the numpy pick is 1.25 or 1.26,
following the existing 0.62/0.63-to-0.64 pattern, and teach validate()
the pairing. The boundary is verified by dry-run solves against
conda-forge: 0.57+1.25 conflicts; 0.58+1.25, 0.58+1.26, and 0.59+1.26
all solve. The --validate stress test passes 160000 combos, and 200
fresh draws produce zero bad pairings.

The matrix hit another conda solver failure: the picker drew pandas 2.2
with scipy 1.9, reachable only on the py3.11 numpy 1.x path, and the
environment could not solve, so the job died before running anything.
conda-forge pandas >=2.2 carries run_constrained "scipy >=1.10.0"
(the latest 2.2.3 build and all 2.3 builds; pandas 2.0 and 2.1 declare
no scipy constraint), and scipy 1.9.3 py311 builds exist even on win-64,
so the pairing fails purely on the pandas constraint. Verified with
conda search --info against conda-forge.

Re-pick scipy from the pool's 1.10 through 1.14 pins whenever a pandas
2.2 or 2.3 pin lands next to a scipy pin below 1.10, and teach
validate() the pairing. The replacement stays pinned below 1.15 because
scipy 1.9 only survives to this point alongside numpy 1.24 or 1.25,
whose scipy ceiling is 1.15. Unpinned pandas is left alone: the solver
backs it off below 2.2 on its own, which keeps scipy 1.9 coverage.

The --validate stress test passes 160000 combos, 4800 fresh draws
produce zero bad pairings, and forcing the old bad pair through
apply_constraints now always lands scipy in 1.10 through 1.14 with no
validate() errors.