CI: consolidate Rust toolchain installs and cache cargo binaries

[bordumb]

Problem

Multiple CI workflows independently install the Rust toolchain and cargo binaries (cargo-deny, cargo-nextest, etc.). Each install adds 30-60s of wall time per job. With matrix strategies, this compounds — a single PR can spend 5+ minutes just on toolchain/binary installs across jobs.

The cargo-deny workflow recently exposed a version skew issue: the Docker-based EmbarkStudios/cargo-deny-action@v2 bundles its own cargo-deny version, which disagreed with the local developer version. This caused CI-only failures that couldn't be reproduced locally.

Proposed changes

1. Pin cargo-deny version in CI to match local. Either use the action (accept its bundled version and upgrade local to match) or install a specific version with caching. The key invariant: cargo deny check must produce the same result locally and in CI.

2. Cache ~/.cargo/bin across jobs. Use actions/cache keyed on a hash of the required binary versions. First run installs; subsequent runs restore from cache. Applicable to: cargo-deny, cargo-nextest, cargo-audit, and any future cargo install invocations.

3. Consider a shared "setup" composite action. A local .github/actions/setup-rust/action.yml that installs the toolchain + caches binaries, called from every workflow. Single source of truth for toolchain version and binary versions.

Current state

• cargo-deny.yml uses EmbarkStudios/cargo-deny-action@v2 (Docker image with bundled binary)
• ci.yml uses dtolnay/rust-toolchain@master with toolchain: "1.93"
• rust-toolchain.toml pins 1.93 at the repo root
• Local cargo-deny: 0.19.4
• No binary caching anywhere

Acceptance criteria

• cargo deny check produces identical results locally and in CI
• Cargo binary installs are cached (cache hit skips install)
• Toolchain version is defined in one place (rust-toolchain.toml) and respected everywhere
• CI wall time for cargo-deny job < 2 minutes (currently ~4 minutes with toolchain install)

Priority

Low — this is developer experience / CI speed, not correctness. But it prevents version-skew debugging sessions like the one that prompted this issue.