perf(ci): experiment with sccache for relay builds

[wesbillman]

Summary

• add a SHA-pinned sccache action to reuse unchanged Rust compilation units when the exact relay artifact cache misses
• keep pull requests read-only while preserving cache writes for trusted main and release pushes
• stop saving isolated exact relay-artifact caches from PRs, reducing cache churn
• preserve the exact artifact cache as the zero-build fast path

Why this is an experiment

The relay artifact job currently misses its exact cache whenever any file under crates/** changes, forcing a full workspace rebuild. PR #4975 spent roughly 21 minutes in that job for a one-file buzz-sdk change. sccache targets the relevant reuse boundary—individual compiler inputs—but the repository cache pool is already under heavy eviction pressure, so this PR does not claim a proven timing win yet.

Safety

• Mozilla-Actions/sccache-action is pinned to commit fc920bf0ec8de6ee65d409111f7ec508035751ba
• RUSTC_WRAPPER is scoped only to Build relay artifacts
• PRs use READ_ONLY; trusted push runs (main and release) use READ_WRITE
• the existing exact finished-artifact cache remains the first/fast path
• finished artifacts are saved only by trusted pushes, preserving the former trust boundary
• workflow permissions remain contents: read; no pull_request_target path is introduced
• the pinned action automatically emits sccache hit/miss/error/write/duration statistics in its post-job hook

Validation

• actionlint .github/workflows/ci.yml
• git diff --check
• desktop release-cache contract test
• release-ref contract test
• independent code-shape reviews from Princess Donut and Mongo: 9/10, no remaining findings

Measurement plan

1. purge obsolete PR-scoped relay-artifacts-* cache entries before measurement
2. merge/push a trusted writer to populate sccache
3. run a representative one-crate PR
4. compare relay job duration and automatic sccache statistics against the 21–22 minute baseline
5. retain this only if the warm run demonstrates material improvement

[wesbillman]

Carl safety review on Wes’s behalf at exact head 54cfe936c87a90c44388c592f3dc992abfc9edc0: I found no correctness or cache-poisoning blocker. The action is SHA-pinned, the downloaded v0.16.0 binary was checksum-verified in the run, RUSTC_WRAPPER is scoped to the relay build step, PR 5224 writes only to its isolated refs/pull/5224/merge cache scope, other PRs are read-only, and only the workflow’s trusted main/release push triggers can populate shared caches. The exact finished-artifact cache remains the first path. The head merges cleanly with current main and the resulting workflow delta is unchanged. Would approve from a safety perspective; GitHub does not permit self-approval from the PR-author account. Operational caveat, not a blocker: the cold proof showed 3/1309 cacheable hits (0.23%), 1,285 writes, and 21 write errors, so benefit and cache-pressure cost remain unproven. Treat the merge as the advertised bounded performance experiment and remove/revert it if the warm measurement does not materially improve the relay job.