ci: simplify system-linker cache via setup-soldr glob-filtered side cache

[zackees]

Context

#50 / PR #51 made the Linux reference-linker downloads (mold, wild, libtinfo5) cache-gated: an actions/cache@v4 step keyed on the pinned versions, plus ci/linker_setup.py which no-ops on a hit and downloads+verifies on a miss. It works, but it is a fair amount of bespoke cache plumbing that every job wanting cached system linkers has to re-implement — the actions/cache step, the key derivation, the path list, and a provisioning script that has to detect the hit and skip work.

The cross-release job already pulls in zackees/setup-soldr for build caching. If setup-soldr could also manage arbitrary extra folders — glob-filtered, in a named side cache, auto-inflated on restore, using soldr's fast zstd archiver — then the whole hand-rolled linker-cache apparatus collapses into a few lines of action config.

That capability is proposed upstream in zackees/setup-soldr#463.

Proposal

Once setup-soldr#463 lands, simplify the system-linker cache management in ci.yml:

• Replace the standalone actions/cache@v4 "Restore cached Linux reference linkers" step with an extra-cache declaration on the setup-soldr step (a named linkers side cache rooted at the linker cache dir, keyed on MOLD_VERSION/WILD_VERSION/LIBTINFO5_VERSION).
• Use glob filters so only the specific artifacts are saved (bin/mold, bin/ld.wild, downloads/*.deb) and transient files are excluded.
• Keep ci/linker_setup.py as the miss-path provisioner (download + SHA-256 verify + materialize), but it no longer needs to know anything about caching — setup-soldr inflates the side cache before it runs, so on a hit it simply finds the artifacts present and no-ops.
• Extend the same pattern to the clang/LLVM apt toolchain if setup-soldr's side cache can hold it (a follow-up left open in ci: adopt setup-soldr caching + cache-gated Python linker setup + cross-compile release builds on parallel Linux runners #50), so the biggest download is cached too.

Net effect: one action does build cache + toolchain + linker side cache, with soldr's high-ratio zstd compression, instead of a separate actions/cache block per cached path.

Acceptance criteria

• The actions/cache@v4 linker step in ci.yml is removed in favor of a setup-soldr extra-cache declaration (blocked on setup-soldr#463).
• Glob filters restrict the saved side cache to exactly the linker binaries + .debs.
• ci/linker_setup.py still provides the miss-path download/verify and stays cache-agnostic; the version-drift smoke step still gates correctness on a hit.
• A warm run restores the linker side cache via setup-soldr (no actions/cache step) and skips all downloads; measured against a cold run.
• No coverage or correctness regression versus PR ci: cache-gated Python linker setup + Linux cross-compile release job (#50) #51's behavior.

Blocked by / cross-reference

• Upstream capability: feat: cache arbitrary extra folders via glob-filtered, zstd side cache (auto-inflate) setup-soldr#463 (cache arbitrary extra folders via glob-filtered zstd side cache). This issue is blocked on that landing.
• Current manual implementation to be simplified: ci: adopt setup-soldr caching + cache-gated Python linker setup + cross-compile release builds on parallel Linux runners #50 / PR ci: cache-gated Python linker setup + Linux cross-compile release job (#50) #51.

Decisions

• Priority: P3. Pure simplification of already-working caching; no behavior gap today. Do it once the upstream feature ships.
• Keep the provisioning script. Even with setup-soldr managing the cache, the miss-path still needs pinned-URL download + checksum verification; that logic stays in ci/linker_setup.py and just stops caring about the cache layer.

[zackees]

Checked as part of the #153 burn-down: the upstream capability this is blocked on, zackees/setup-soldr#463 (glob-filtered zstd side cache with auto-inflate), is still open. Nothing here can land without it, and the hand-rolled actions/cache@v4 step from #50/PR #51 is working, so this stays parked rather than being replaced with a second bespoke mechanism.

Re-check when 463 closes; the acceptance criteria above still describe the change exactly.