fix(cache): exclude rust from mise cache

[risu729]

Summary

• exclude mise-managed Rust installs from the saved mise-action cache
• restore the Rust install path after saving so later workflow steps can still use it
• document that mise-action does not save Rust toolchains and recommend a Cargo-aware cache for Rust projects

Notes

@actions/cache.saveCache does not support per-path exclusions when saving a cache path. To keep the current job behavior intact, this PR temporarily stages installs/rust outside MISE_DATA_DIR, saves the mise cache, then restores it in a finally block.

I checked the mise Rust backend: downloads/rust is not read as a reusable cache. Rust installs go through rustup, rustup state lives under RUSTUP_HOME/CARGO_HOME, and mise only creates downloads/rust/<version> via generic install scaffolding. That directory is removed after successful install unless always_keep_download is enabled, where it is retained for debugging rather than reuse.

This replaces the previous docs-only approach after the mise-side fix was declined.

Test plan

• npm run format:write
• npm run lint
• npm run package

This PR body was generated by an AI coding assistant.

[greptile-apps]

Greptile Summary

This PR excludes installs/rust from the mise-action cache by temporarily staging it outside MISE_DATA_DIR before saving, then restoring it in a finally block so later workflow steps are unaffected. Documentation is also added recommending Swatinem/rust-cache for Rust projects.

• Staging/restore logic (src/index.ts): stageRustCachePaths renames installs/rust to a sibling directory named with process.pid and Date.now(), and restoreRustCachePaths moves it back regardless of whether cache.saveCache succeeded or failed.
• README documentation: A new section explains that mise-action does not cache Rust toolchains and shows the recommended Swatinem/rust-cache follow-on step.

Confidence Score: 5/5

The staging/restore approach is structurally sound — the finally block guarantees installs/rust is always returned to its original location, and no new logic defects were found in the changed code paths.

The core try/finally contract is correct: the Rust path is always restored regardless of whether saveCache succeeds, is skipped (cacheId -1), or throws. The staged-path naming (pid + timestamp + relative path) is unique enough for sequential execution. No new logic defects were found in the changed code paths during this review pass.

src/index.ts — specifically the RUST_CACHE_PATHS constant and how stageRustCachePaths handles multiple entries if new paths are added in future.

Important Files Changed

Filename	Overview
src/index.ts	Adds RUST_CACHE_PATHS constant and stageRustCachePaths/restoreRustCachePaths functions to temporarily move installs/rust out of MISE_DATA_DIR during cache save; the try/finally wrapping is correct but the function has edge cases around partial staging failure when multiple paths are present.
README.md	New "Rust and Cargo Caches" section added with guidance on using Swatinem/rust-cache; description of Swatinem/rust-cache behaviour has some minor inaccuracies already flagged in prior review threads.
dist/index.js	Compiled bundle regenerated to match src/index.ts changes; no independent review needed.
dist/index.js.map	Source map regenerated alongside the new bundle; no issues.

_{Reviews (4): Last reviewed commit: "fix(cache): exclude rust from mise cache" | Re-trigger Greptile}

[greptile-apps]

The ~/.cargo description is a slight over-simplification. Swatinem/rust-cache does not cache the entire ~/.cargo tree — it caches specific subdirectories (registry/index, registry/cache, git/db) plus ~/.cargo/bin (when cache-bin: true, the default) and the target directory. Notably, ~/.cargo/registry/src is explicitly not cached because cargo recreates it from the compressed archives. Saying "caches ~/.cargo and target" may lead users to assume all cargo data is persisted when it isn't.

Suggested change

	`Swatinem/rust-cache` caches `~/.cargo` and `target` by default, including
	`~/.cargo/bin` for tools installed during the workflow. If your workflow uses a
	custom `CARGO_HOME`, or installs Cargo tools somewhere else, add that directory
	to your cache configuration manually.
	`Swatinem/rust-cache` caches the Cargo registry, git dependencies, `~/.cargo/bin`,
	and `target` by default. If your workflow uses a custom `CARGO_HOME`, or installs
	Cargo tools somewhere else, add that directory to your cache configuration manually.

[gemini-code-assist]

Code Review

This pull request updates the README.md to include a new section on Rust and Cargo caching, recommending the use of Swatinem/rust-cache alongside mise-action. The review feedback suggests improving the technical accuracy of the documentation by specifying the exact subdirectories cached within the Cargo home and noting that mise-action automatically exports CARGO_HOME, which simplifies the integration.

[gemini-code-assist]

It is more accurate to state that Swatinem/rust-cache caches the Cargo registry, git database, and binaries (~/.cargo/{registry,git,bin}) rather than the entire ~/.cargo directory. Additionally, since mise-action exports environment variables like CARGO_HOME to GITHUB_ENV, rust-cache will typically pick them up automatically. Manual configuration is usually only necessary for non-standard tool installation paths outside of the Cargo home.

[risu729]

Opened a README-only follow-up with the verified workflow workaround in #482. Leaving this PR as-is for now; #482 is the narrower docs path for the Rust cache issue.