rust: normalize cache keys with SCCACHE_BASEDIRS

[tcashel]

Hi! I use ccache heavily for C and C++ projects, and I have been trying sccache for my Rust builds.

Problem

I often have several coding agents build the same Rust commit from separate Git worktrees. Because each worktree has a different absolute path, sccache treats the builds as different, repeats the compilation, and creates duplicate cache entries.

Change

This PR makes Rust cache keys honor configured SCCACHE_BASEDIRS. Matching paths are hashed relative to the longest configured root. Nonmatching paths keep their current behavior.

For example, a daemon configured with /work/project and /tmp/project-worktree can reuse a Rust artifact between those checkouts when their inputs match.

The matcher checks each configured root without allocating. The change also bumps the Rust cache-key version from 6 to 7 so the new framing cannot collide with older keys.

Follow-up draft #2814 makes SCCACHE_BASEDIRS request-scoped so one daemon can serve new worktrees without restarting. It is one commit on top of this branch; view the follow-up-only diff.

Validation

The locked unit and integration suites, clippy, rustfmt, and Taplo pass on Apple silicon. The Cargo integration test builds the same crate under two roots, observes a cache hit, and verifies that a source change misses.

I ran the repository benchmark suite on Apple silicon. cache_key_generation had a 31.41 µs median on both main and this branch. The new matcher took 0.208 µs for 100 lookups with one configured root and 4.33 µs with 32 roots.

Compatibility and limits

This behavior is opt-in. It changes cache keys, not paths embedded in artifacts. If code embeds CARGO_MANIFEST_DIR, a cache hit can contain the path from the compilation that populated the cache. Use rustc path remapping when that embedded path must match the current checkout.

On Windows, matching accounts for ASCII case and separator differences. Non-ASCII path values remain unchanged.

This draft is an alternative to PR #2678 and PR #2794, and relates to issue #2595.

I used OpenAI Codex (gpt-5.6-sol, ultra reasoning) during implementation, testing, benchmarking, and review. I'll review the full diff and CI results myself before marking the PR ready.