chore(ci): remove obsolete Rust cache seeder

[pimlock]

Summary

Remove the obsolete Rust Cache Seed workflow. Recent CI changes moved Rust checks to Nix and changed their cache keys, so the seeder no longer warms caches used by branch checks.

Branch-check build times remain comparable to the previous setup. The retained Cargo cache will continue to help repeated checks on the same PR branch after its first run.

Related Issue

No issue required: this is a localized CI cleanup that removes a stale, non-required optimization workflow.

Changes

• Delete .github/workflows/rust-cache-seed.yml.
• Leave the Nix and Cargo caching used by branch checks unchanged.
• Leave required CI gates unchanged.

Testing

• mise run pre-commit passes
• Confirmed no repository references remain to the removed workflow or its cache namespaces
• Unit tests not needed because this only deletes a standalone workflow
• E2E tests not needed because runtime behavior is unchanged

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs not applicable

[pimlock]

Investigation notes

The removed seeder was added in 521eccd47 for the former container-based Rust jobs. Branch checks moved to Nix in 8d16a59e, but the seeder was not migrated with them.

Cache compatibility

• The seeder still uses the CI container, mise, and sccache. Current branch checks use Nix, Cachix, and Cargo commands inside the flake's development shell.
• The seeder writes Cargo caches named rust-checks-linux-amd64-cpu8 and rust-checks-linux-arm64-cpu8.
• Current branch checks request rust-checks-x86_64-linux, rust-checks-aarch64-linux, and rust-checks-aarch64-darwin.
• The current GitHub cache inventory contains main-branch entries under the old runner-based names, while current branch jobs miss using the Nix system-based names. Updating only the key would still leave the seeder's toolchain, environment, cache options, and platform matrix different from branch checks.

The retained Swatinem/rust-cache action is working for repeated runs on one PR branch. A failed run of PR #3129 missed and saved its caches; the following run restored exact matches on x86_64 Linux, aarch64 Linux, and aarch64 macOS. The actual restores took about five to seven seconds.

Cache reuse is scoped and inconsistent across refs. A later PR #3073 run restored exact Linux caches on x86_64 and aarch64, while its macOS job missed. The branch-check run for this PR and a sampled merge-group run missed on all three platforms, as expected without compatible default-branch entries.

Current Cargo cache archives are large: approximately 2.1 to 3.1 GB per platform. In the PR #3073 sample, restoring the roughly 2 GB Linux caches took 67 to 80 seconds. The warm x86 job finished about 75 seconds faster than its earlier cold run, while ARM finished about 35 seconds faster.

Duration and workflow cost

• Successful Branch Checks were sampled before the Nix migration, immediately after it, and in recent runs.
• Median whole-workflow duration was 13:37 before Nix, about 10:09 immediately after Nix, and 12:55 currently.
• Compared with the old workflow, current median x86 Rust duration is about 1:08 slower, ARM is about 1:01 faster, and the whole workflow is about 42 seconds faster.
• The macOS comparison is not like-for-like: the former job ran focused linting, while the Nix job runs the full suite and later-added verification steps.
• Most growth since the initial Nix migration comes from telemetry, feature-alias, and CA-root verification added later. Nix setup and shell realization remain stable at roughly 29 seconds on x86 Linux, 33 seconds on ARM Linux, and 71 seconds on macOS. Run 33682987349 is representative.

The seeder itself runs two full Rust jobs after every main merge and recent successful runs took roughly 8 to 13 minutes. It also uses cancel-in-progress: true; 23 of the last 99 completed seed runs inspected were cancelled. For example, run 33671828795 for 1e1a8b58 was superseded after its x86 test completed and while ARM was still testing.

Given the incompatible configuration, comparable branch-check duration, large cache archives, and modest observed savings, deleting the seeder is preferable to rebuilding it around the current Nix jobs. If cold first-run compilation becomes a measured bottleneck, a replacement should be designed around the current Nix environment and exact cache semantics rather than restoring the old workflow.