ci: Ensure rust-cache respects versions in Cargo.lock

[kylebarron]

[This PR summary written by claude]

Summary

Add an explicit key: to Swatinem/rust-cache in all three workflows that use it, so Cargo.lock changes actually invalidate the cache. Also segment the test-python cache by matrix.python-version.

Why

Swatinem/rust-cache normalizes dependency version numbers to "0.0.0" before hashing Cargo.lock to compute its cache key. This means a patch/minor bump like pyo3 0.28.2 → 0.28.3 produces the same cache key as before the bump. rust-cache's stale-crate cleanup only runs on partial (restore-key) hits — on a full-match hit it trusts the cached target/ as-is, so stale pre-compiled artifacts can be reused indefinitely.

This bit us on #673 (cherry-pick of #672 into release/py-v0.9): after the PyO3 0.28.3 bump, the release-branch CI kept restoring a pre-0.28.3 target/ from cache and the 3.14t job failed with SystemError: init function of _obstore returned uninitialized object. Main passed only because it happened to get a partial cache hit, which triggered rust-cache's cleanup and forced a fresh PyO3 rebuild.

Appending hashFiles('**/Cargo.lock') to the cache key means any byte-level change to any lockfile in the repo produces a new cache entry. No more silent staleness.

Why segment test-python by Python version

pyo3-build-config's build.rs detects the target Python ABI via environment variables (PYO3_PYTHON, PYTHON_SYS_EXECUTABLE) set by maturin at build time. Those env vars are not part of cargo's fingerprint, so cargo can reuse target/ artifacts built against Python 3.14 when the next matrix job runs under 3.14t — producing ABI-incompatible .sos with exactly the symptom we just debugged. Giving each matrix entry its own cache slot makes this class of cross-contamination structurally impossible.