ci: warm release build caches from main

[geoffjay]

Tag-triggered release runs can only restore Actions caches created on the
default branch, so the rust-cache step in release.yml never hit and every
release compiled all dependencies from scratch (~40-60 min per target).

Add a cache-warm workflow that runs the same release-mode build matrix on
main (on Cargo.lock changes, weekly, or manually) under a shared rust-cache
key, and switch release.yml to restore that key without saving — caches
saved on tag refs are unreachable by future runs and only consumed quota.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

[geoffjay]

This change is part of the following stack:

• ci: warm release build caches from main #1259 ◀

_{Change managed by git-spice.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.13%. Comparing base (d9aaee7) to head (cf609a1).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1259   +/-   ##
=======================================
  Coverage   46.13%   46.13%           
=======================================
  Files         390      390           
  Lines       27293    27293           
  Branches     2501     2501           
=======================================
+ Hits        12591    12592    +1     
+ Misses      14680    14679    -1     
  Partials       22       22           

Flag	Coverage Δ
frontend	68.29% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[geoffjay]

Code Review: ci: warm release build caches from main

Note: GitHub prevents approving your own PR, so posting as a comment. No blocking issues found — this is a clean, well-reasoned CI fix.

Stack position

Targets main directly — appropriate for a CI operational fix rather than feature code.

Correctness

The GitHub Actions cache scoping is correctly understood and implemented throughout:

• shared-key vs key: key appends to rust-cache's auto-generated key; shared-key replaces the entire key with a stable prefix. Using shared-key: release-${{ matrix.target }} identically in both workflows gives them a predictable, matching lookup key — this is the correct approach for cross-workflow cache sharing.
• save-if: false in release.yml: tag-ref saved caches are unreachable by future runs (Actions only restores from the current ref or the default branch). Saving on a tag ref wastes quota and is never reused — disabling it is correct.
• Matrix parity: all four targets and runner images in cache-warm.yml match release.yml exactly. ✓
• Concurrency group: cache-warm-${{ github.ref }} resolves to refs/heads/main for all three triggers (push, schedule, dispatch); cancel-in-progress: true correctly aborts a stale warming run when a newer Cargo.lock push arrives. ✓
• Weekly cadence (0 6 * * 1 — Monday 6am UTC): keeps caches alive past GitHub's 7-day eviction window between releases. ✓
• fail-fast: false: correct — one target failing to warm shouldn't block the others. ✓
• Existing ci.yml uses key: (not shared-key:): intentional and correct. CI jobs don't need cross-workflow cache sharing, so the auto-derived key works fine there. The inconsistency is justified by the different requirements.

Non-blocking suggestion

The matrix in cache-warm.yml is a maintained copy of release.yml's matrix, linked by a comment:

# Must mirror the build matrix in release.yml.

There is no enforcement. A new release target added to release.yml and missed in cache-warm.yml would silently skip warming for that platform — the next release for that target would compile from scratch without any indication of why. Consider mirroring the note in release.yml next to its own matrix block as a reminder, e.g.:

# If you add a target here, add the same entry to cache-warm.yml.

Not a blocker — approving.