rust: normalize cache keys with SCCACHE_BASEDIRS

[tcashel]

Rust builds of the same source in different worktrees currently get different cache keys. This makes Rust hashing honor SCCACHE_BASEDIRS, using the longest matching root for source paths, remap sources, relevant environment values, and the working directory. The Rust cache-key version advances to 7.

This is opt-in and changes cache keys, not embedded artifact paths. A cached crate using env!("CARGO_MANIFEST_DIR") can retain the original checkout path. Tests cover cross-root reuse, source-change misses, argument framing, and Windows path forms.

Rebased onto current upstream. Formatting, clippy, and the locked unit/integration suite pass on Apple silicon. CUDA cases skip locally; native Windows and CUDA validation are left to CI.

Request-scoped configuration follows in #2814. Related to #2595. Developed with OpenAI Codex.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 98.97119% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.93%. Comparing base (b45240d) to head (08905ef).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
src/compiler/rust.rs	99.17%	2 Missing ⚠️
src/util.rs	98.74%	2 Missing ⚠️
tests/sccache_cargo.rs	98.52%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2813      +/-   ##
==========================================
- Coverage   73.71%   71.93%   -1.78%     
==========================================
  Files          72       72              
  Lines       37932    38431     +499     
==========================================
- Hits        27963    27647     -316     
- Misses       9969    10784     +815     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tcashel]

@sylvestre This is ready for review. #2814 and #2838 are stacked follow-ups. The new CI runs are also waiting for maintainer approval. Thanks! Please let me know if i'm doing something wrong, in code or in process!