ci: cache Rust toolchain, registry and build directories

Every Rust job restores the stable toolchain, Cargo registry and its own
target directories from the runner cache. Keys combine the ISO week and
all Cargo.lock files, so dependencies are reused across pushes while
stale build output and old toolchains expire weekly. Release jobs keep
separate entries per plugin.

docs/releases.md

@@ -64,6 +64,24 @@ Node runtime, and a local composite action installs Rust and build dependencies.
 Windows binaries are cross-compiled with MinGW; no Windows runner or Linux release
 binary is required.
 
+### Build cache
+
+Every Rust job restores two caches through the runner's cache server
+(`actions/cache@v4`, run from the setup composite action):
+
+- **Toolchain:** rustup's stable toolchain, Cargo's binaries, and the registry and
+  git sources, keyed by ISO week, Windows target, and all three `Cargo.lock` files.
+- **Build directories:** each job's target directories (check per plugin,
+  previews, Windows preview, release per plugin), keyed the same way.
+
+A new week or a changed lockfile starts a fresh entry, so stale build output does
+not accumulate and the stable toolchain refreshes weekly. Within a week, pushes
+reuse compiled dependencies and rebuild only this repository's crates. Release
+jobs use their own entries and never reuse branch build output. A cache miss only
+costs time. The runner's cache server must be enabled (`cache.enabled` in
+`act_runner`'s config, the default) and must support post steps of actions
+inside composite actions (current `act_runner` releases do).
+
 The workflows use explicit action URLs and the v3-compatible artifact protocol.
 Only the publish job requests `contents: write`. It authenticates against the
 same Gitea instance using the automatic `secrets.GITEA_TOKEN`; no personal access