chore: deterministic dependency pinning (SHA-pin getdist, camb floor, scipy root-cause)

[cailmdaley]

Why

The container installs via uv pip install -e .[test,glass], which resolves fresh from pyproject.toml and never reads a lockfile (uv.lock is gitignored). So pyproject.toml is the real source of truth for what gets installed at build time. This PR tightens constraints only where resolution is non-deterministic or known-broken — it does not freeze the stack.

Scope deliberately narrow: no uv.lock, no Dockerfile change, caps only where there is a known breakage (today: only scipy).

Per-dependency changes

dep	old constraint	new constraint	why
scipy	<1.18 (kept)	<1.18 (kept; comment sharpened)	scipy 1.18 breaks camb's BBN predictor — see root cause below. Cap unchanged; comment now records the precise mechanism + lift trigger.
camb	(unpinned)	>=1.6	hygiene floor at current latest. No cap — we want the eventual scipy-1.18 fix release. Revisit the scipy cap when camb ships > 1.6.6.
shear_psf_leakage	@develop	@develop (kept)	Actively co-developed CosmoStat code — intentionally tracks develop so we stay current. SHA-pinning would only create bump-churn (Cail's call).
getdist	@upper_triangle_whisker (branch)	@113cd22a9a0d013b6f72fe734be81f260f3d3be5	External feature-branch fork (not co-developed) — SHA-pin the current snapshot for reproducibility.
jupytext	==1.15.1 (exact)	>=1.15	stale exact pin, not load-bearing; relax to a floor.

Everything else (numpy>=2.0, treecorr>=5.0, astropy>=5.0, cs_util>=0.2.1, joblib>=0.13, the glass exact-pin group, the docs floors) is left as-is. Goal is "properly versioned + modern," not frozen.

scipy / camb root cause

scipy 1.18.0 (2026-06-19) ported FITPACK from Fortran to C, which changed the return shape of spline evaluation for scalar input:

RectBivariateSpline(scalar, scalar, grid=False):
  scipy 1.17 -> array(0.247026)     # 0-d
  scipy 1.18 -> array([0.247026])   # shape (1,)

camb's BBN Y_He predictor (camb/bbn.py) wraps the result in np.float64(res). That collapses a 0-d array to a clean scalar but leaves a shape-(1,) array as (1,). set_cosmology then fails at the ctypes float assignment self.YHe = YHe:

TypeError: only 0-dimensional arrays can be converted to Python scalars

…which fails every get_cosmo-backed test. camb 1.6.6 is the latest on PyPI and current camb master is also unfixed — there is no camb release to bump to. The upstream fix is one line (coerce the (1,) result to a scalar); when it ships in a release > 1.6.6, the scipy cap can be lifted.

In-code breakage scan: clean

A scan of tracked sp_validation source (src/, scripts/, workflow/, cosmo_val/, cosmo_inference/) for the scipy-1.18 scalar-shape change, numpy-2 removed/renamed names, and astropy Quantity scalar extraction found zero hits. All interp1d / RectBivariateSpline usages operate on arrays; tests already use np.trapezoid. The only victim of the scipy change in the whole stack is camb's internal BBN predictor (third-party), so the scipy cap is the correct and sufficient fix — no sp_validation code change is needed.

Verification

• The getdist SHA-pin confirmed a valid commit via git ls-remote.
• uv pip compile pyproject.toml (to a throwaway path, no lockfile written) resolves cleanly (exit 0): scipy==1.17.1 (cap binds), camb==1.6.6, cs-util==0.2.1, jupytext==1.19.3, getdist at its pinned SHA, and shear_psf_leakage tracking develop.

— Claude on behalf of Cail