sccache's cache is on GitHub's built-in actions/cache, cappe…

Move sccache's cache off GitHub's built-in actions/cache onto an external backend sccache natively supports (S3, GCS, Azure Blob, or a self-hosted Redis/webdav endpoint). The cache would then be bounded by whatever storage is provisioned rather than GitHub's fixed 10 GB per-repository quota, would no longer compete with unrelated OS/compiler variants for that shared quota, and would no longer be subject to GitHub's 7-day-unused eviction policy.

GitHub's actions/cache is capped at a fixed, non-purchasable 10 GB per repository, shared across every OS/compiler/buildtype variant (linux-gcc/clang, windows-clang, macos-clang × debug/release) plus the vcpkg and Qt install caches. Confirmed via a live experiment in sprint 22 (story canary_ctest_ignores_cancellation): a PR with essentially zero source diff still got a 0.00% sccache hit rate, because the Linux-gcc-debug cache that canary-linux.yml depends on (and which gates every PR) had been evicted entirely by GitHub's LRU policy to make room for other platforms' caches, touched more recently by continuous-*.yml runs elsewhere in the repo.

The immediate mitigation landed in PR #1418 (stop persisting sccache for windows/macos continuous builds, so Linux gets the shared quota to itself) only reduces the contention — it doesn't remove it, and doesn't scale as more variants or heavier builds are added. An external backend removes the constraint at the root instead of continuing to ration a fixed 10 GB across a growing set of build variants.

• Canary CI: near-zero sccache hit rate makes every build a cold rebuild — the story that diagnosed this.
• PR #1418 — the immediate (partial) mitigation.
• sccache S3 backend docs (and sibling docs for GCS/Azure/Redis/webdav in the same docs/ directory) — configuration reference for whichever backend is chosen.