Specify the muP mechanism crossover predictor before implementing it #12

Why

mechanism_crossover_budget is an honest stub: it raises NotImplementedError and must never return a fabricated intersection. The naive power-law intersection is already implemented and is known to go blind under saturation. That limitation is a result, not a bug.

What to do

Before writing code:

1. Write the statistical/physical specification: inputs from muP/parameterization, the equation for a crossover budget, and when it should return None.
2. List required logged fields beyond the current schema.
3. State how it will be tested on saturation_crossover vs clean_crossover.
4. Only then implement, keeping the naive predictor unchanged.

Acceptance

• Spec is reviewed before a number-returning implementation
• Stub still raises until that spec exists
• Naive predictor still returns None on the saturating pair
• Tests prevent a placeholder float from being reported as a mechanism prediction

Files

• asla/analysis/crossover.py
• tests/test_predictors.py

Do not fabricate

• Return a numeric guess, interpolation, or copied naive root from the stub