Standardize Rust toolchain setup and cache ownership

[Teakowa]

Goal

Define and validate a WrightKit-wide Rust CI pattern that keeps toolchain setup and cache policy explicit, independently reviewable, and bounded across repositories.

Context

Current WrightKit Rust repositories commonly use actions-rust-lang/setup-rust-toolchain, which combines toolchain provisioning with an implicit Swatinem/rust-cache integration. That was a reasonable incremental choice while fixing cache growth, but it makes cache behavior less visible in workflow YAML and couples two separate concerns:

• Rust toolchain / components / targets;
• Cargo registry/git/target cache policy.

The recent cache audit in #2 established a WrightKit-specific bounded-cache policy: PRs should not become persistent cache writers, failed jobs should not save caches, and new cache families require evidence.

For long-term maintainability, WrightKit should evaluate making these responsibilities explicit, preferably with a dedicated toolchain setup step plus Swatinem/rust-cache as the visible cache owner rather than relying on an all-in-one wrapper.

LPP PR wrightkit/language-provider-protocol#8 is the intended pilot for this structure.

Scope

• Define the preferred WrightKit Rust CI composition for:
  • toolchain selection and component installation;
  • Cargo.lock / --locked use;
  • Cargo registry/git cache;
  • target cache where evidence supports it;
  • main-only writers and restore-only PR/secondary jobs;
  • release/tag jobs that intentionally disable cache.
• Use language-provider-protocol#8 as the first implementation/pilot.
• After the pilot has real main-seeded cache-hit evidence, assess whether the same pattern should replace actions-rust-lang/setup-rust-toolchain in:
  • wrightkit/wright
  • wrightkit/opy-rs
  • wrightkit/del-rs
  • wrightkit/workshop-rs
• Keep repo-local implementation work in each owning repository rather than implementing cross-repo workflow changes from this issue.

Non-goals

• Migrating every Rust repository immediately for stylistic consistency.
• Replacing Swatinem/rust-cache with a custom actions/cache key scheme without evidence that the Rust-specific action is insufficient.
• Creating a shared workflow/complex abstraction before repeated repo-local usage demonstrates that it is useful.
• Changing compiler/tooling semantics or test coverage.

Acceptance criteria

• The preferred WrightKit Rust CI responsibilities and bounded-cache rules are explicit and understandable from workflow configuration without relying on hidden wrapper defaults.
• The LPP pilot demonstrates successful CI and at least one main-seeded cache restore on a subsequent run before being treated as the reference pattern.
• Any later repo migration is justified by maintainability or measured CI behavior, not only by ecosystem fashion.
• Repo-local migrations preserve existing validation coverage and release behavior.
• Cache family count and writer behavior remain bounded after any migration.

Dependencies

• Audit and bound Rust CI build work across WrightKit #2
• perf(ci): share one bounded Rust cache language-provider-protocol#8

Planning notes

Prefer explicit responsibility separation over wrapper convenience, but do not churn working workflows without evidence. The target is clearer ownership and easier cache governance, not simply matching popular community YAML patterns.