Make pixi cuda-version pins track ci/versions.yml to prevent toolkit-version drift

[rparolin]

Problem

The canonical CUDA build version lives in ci/versions.yml (cuda.build.version), and the generated Cython bindings carry a # generated with version X stamp. But the local pixi run test path pins CUDA independently via cuda-version in cuda_bindings/pixi.toml and cuda_core/pixi.toml ([workspace.build-variants] + [feature.cu13.dependencies]).

These drifted: #2139 regenerated the bindings to 13.3 but left the pixi pins at 13.2, which silently broke pixi run test while CI stayed green (see #2182, fixed by #2180). This will recur on the next CUDA bump.

Proposal

Have the pixi cuda-version pins derive from / stay in lockstep with ci/versions.yml (e.g. a check or a generation step), so a toolkit bump can't leave the local test env behind.

Related latent weakness

While diagnosing #2182, two local caches did not invalidate when the CUDA header version changed underneath them, producing confusing errors:

• the pyclibrary parser cache (CUDA_PYTHON_PARSER_CACHING=1 → cache_driver/cache_runtime) regenerated driver.pyx referencing a struct member the new 13.3 header had dropped;
• setuptools build_ext left a stale compiled cython-test .so (a size changed binary-incompat error).

Both are gitignored local artifacts (absent on a clean checkout), but worth considering whether a CUDA-version change should invalidate them.

🤖 Filed with Claude Code