ci: evaluate a main-owned Rust dependency cache

Problem

Recent successful code CI runs spend a median of 3m30s in the Rust job, with a 2m48s to 3m56s range. Clippy takes a median 1m06s and cargo test takes 2m06s.

On https://github.com/NVIDIA-NeMo/Switchyard/actions/runs/34497080857, Rust took 3m35s while the longest Python job took 5m05s. A Rust cache should save runner time and return Rust results sooner, but it probably will not shorten the full required CI run yet.

Switchyard currently has no Rust cache. Its existing Actions caches are about 55 MB of uv data.

Proposed trial

Add a SHA-pinned Swatinem/rust-cache step only to the Rust job in .github/workflows/ci.yml.

• Use the v2.9.1 SHA already used by NeMo Relay.
• Set cache-bin to false.
• Save only from main; pull requests can restore the cache written by main.
• Keep the action defaults. Do not add shared keys or cache workspace crates.
• Leave Python, docs, portability, perf, publishing, and release workflows alone.

This should be a four-line workflow change.

Risks

Cache download time may cancel out the compile savings. New lockfile and toolchain generations also consume storage until GitHub evicts them. The default repository cache limit is 10 GB.

Fork pull requests can read the main cache, so it must not contain secrets. Main-only writes, cache-bin false, and a pinned action SHA keep the trust boundary narrow. A missing or bad cache must fall back to a normal Cargo build.

Validation

1. Seed the cache from a main run.
2. Verify pull requests restore but do not save it.
3. Record cache size and restore/save time.
4. Compare at least 5 warm runs against the current 3m30s Rust median.
5. Keep it only if the Rust job improves enough to justify the storage and maintenance cost.

Local Cargo runs can show that warm artifacts help, but cache scope, archive size, and Actions timing have to be measured on GitHub.

Start in .github/workflows/ci.yml at the Rust job and compare the proposed Swatinem/rust-cache version with the SHA used by NeMo Relay. Seed the cache from a main run, then verify pull requests restore without saving. Record cache size and timing across at least five warm runs, and keep the change only if the Rust job improves enough to justify the cost.