fix(tests): resolve checkpoints under the current store roots

[inureyes]

What was wrong

tests/common/mod.rs::repo_model_dir resolved a checkpoint only under models/<name>. Every one of its 164 call sites treats a missing directory as "skip this test", so pointing at the wrong root does not fail: it turns the test into a no-op that still reports ok.

The store was consolidated into models/mlx/ (with checkpoints over 120GB in models/mlx-big/) and the lookup was never moved with it. Measured on the M1 Ultra tree: of the 30 distinct model names used across tests/, zero resolve under models/<name>. Every real-model integration test in the repository is currently skipping while the suite stays green.

tests/mamba2_hybrid_finite.rs is the case that surfaced this. It is the NaN guard written in #1718, the one whose whole point was that the safety claim in granitemoehybrid.rs and falcon_h1.rs rested on a test that did not exist. It exists now, and it was skipping: finished in 0.00s, two tests reported ok, 500 forwards never run.

What changed

repo_model_dir searches models/, models/mlx/, models/mlx-big/, and the two mlxcel-internal equivalents, first hit wins. On a miss it returns the same non-existent path as before, so the callers' skip behavior is unchanged.

MLXCEL_REQUIRE_MODELS=1 turns a miss into a panic that names every root tried. That is the part that stops this recurring: a local gate run can no longer pass by skipping everything, and the next store move fails loudly instead of quietly. CI has no checkpoints and leaves the variable unset.

Validation

Before: cargo test --test mamba2_hybrid_finite finished in 0.00s, 2 passed. After: 10.64s, 2 passed, 250 forwards per checkpoint actually run. That pair is the evidence the change does something.

The flag was falsified with a throwaway probe calling repo_model_dir("this-checkpoint-does-not-exist-4bit"): unset it returns models/this-checkpoint-does-not-exist-4bit with exists=false and the test passes; set to 1 it fails with resolves nowhere. Tried: <five paths>.

cargo clippy -p mlxcel --all-targets and cargo fmt --all -- --check are clean. Workspace clippy is red on main for two unrelated lints in mlxcel-core, fixed in #1720.

Known remainder

15 of the 30 names now resolve. The other 15 are renames from the same consolidation (llama-3.1-8b-4bit is now meta-llama-3.1-8b-instruct-4bit, qwen2.5-7b-4bit is qwen2.5-7b-instruct-4bit, gemma3-1b-4bit is gemma-3-1b-it-4bit) or genuinely gone. Mapping them needs per-name judgment rather than a sed: jamba-v0.1-4bit has no successor in the store, and the nearest name, ai21-jamba-reasoning-3b-4bit, is a different model. Pointing a parity test at the wrong checkpoint is worse than skipping it, so those are left for a follow-up pass with MLXCEL_REQUIRE_MODELS=1 as the checklist.