ci(windows): cache Rust builds in the release-windows-check lane

[Rangsh]

Add Kache install, restore, report, and save steps to the package job so the runtime-host-peer and sandbox launcher release builds reuse a warm cache on windows-2025, following the pattern already used in windows-sandbox-w0.yml.

Summary

Release Windows check is the slowest PR lane in this repository and the only one that compiles Rust without a build cache. The Package the Windows installer and ZIP step alone averages ~10m54s, largely because it runs two cold Rust release builds on windows-2025:

• npm run build:runtime-host-peer (native/runtime-host-peer, cdylib)
• cargo build --manifest-path experiments/windows-sandbox/launcher/Cargo.toml --release --locked (sandbox launcher)

This PR adds Kache install, restore, report, and save steps to the package job in .github/workflows/release-windows-check.yml, following the same pattern already used in windows-sandbox-w0.yml:

• kache@0.16.0 via the same pinned taiki-e/install-action
• KACHE_CACHE_DIR, KACHE_RUNTIME_DIR, and RUSTC_WRAPPER=kache injected before packaging
• cache key scoped to windows-2025, rustc version, and commit revision
• kache report written to the GitHub Actions step summary for warm-cache measurement
• cache saved only on the default branch

No verification logic changes. The lane still runs the same end-to-end checks, including Verify the Windows release, so a stale cache cannot silently pass.

Fixes #4470

Verification

• Reviewed .github/workflows/release-windows-check.yml against windows-sandbox-w0.yml and confirmed the Kache wiring matches the existing repository pattern (install pin, env vars, restore/save actions, default-branch save guard).
• Confirmed scripts/package-windows-x64.mjs builds both Rust targets inside the cached step and inherits process.env, so RUSTC_WRAPPER=kache applies to both build:runtime-host-peer and the sandbox launcher cargo build.
• Confirmed npm run clean only removes TypeScript dist outputs and does not delete Rust target/ directories, so it does not defeat Kache.
• Full Release Windows check workflow on windows-2025 — not run locally; requires CI to measure warm-cache impact against the ~10m54s baseline from the issue.

Expected CI evidence after merge:

• kache report appears in the workflow step summary
• Package the Windows installer and ZIP is faster on a warm cache than the issue baseline
• the lane still passes end to end, including Verify the Windows release

Rollout

The save step only runs when github.ref_name == github.event.repository.default_branch, so pull_request runs restore the cache but do not write it. That is fine: this workflow also runs on a nightly schedule (17 5 * * *) and via workflow_dispatch, both on main, so the default-branch cache is populated automatically without any manual seeding after merge.

On Windows, Kache caches runtime-host-peer fully as a cdylib. The sandbox launcher is a bin crate, so dependency crates are cached but the final .exe may still be rebuilt unless KACHE_CACHE_EXECUTABLES is enabled later. That matches the current windows-sandbox-w0.yml behavior and is acceptable for this issue's scope.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope:

Cursor (Auto) drafted the workflow change and PR description based on issue #4470 and the existing windows-sandbox-w0.yml reference implementation.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Approving. I went looking for the failure mode where the save step never fires — github.ref_name == default_branch is false on every pull_request run — but this workflow's on: also carries schedule: '17 5 * * *' and workflow_dispatch, so the nightly on main populates the cache on its own. The job-level defaults.run.shell: bash covers the new bash-syntax steps on windows-2025, and the wiring matches windows-sandbox-w0.yml step for step.

One correction for the PR body rather than the diff: it says "This workflow is PR-triggered and does not save cache from feature-branch runs", which reads as if a maintainer has to seed the cache by hand after merge. The nightly does it — no manual workflow_dispatch needed.

[Rangsh]

@Astro-Han Thanks for the review and the catch on the Rollout section — you're right. I've updated the PR description to note that the nightly run on main seeds the default-branch cache automatically, so no manual workflow_dispatch is needed after merge.

[Astro-Han]

One thing to take with a rebase: #4461 added Rust build caches publish immutable source generations only from the default branch to scripts/ci-workflow-policy.test.mjs, which asserts exactly five workflows use kache@0.16.0. This PR makes it six, and the other assertions there (revision-suffixed key, Save gated on the default branch) already hold for your change, so bumping that count to 6 is the whole fix. The earlier planning runs first failure was a stale merge ref and goes away with the rebase.

[Rangsh]

@Astro-Han Thanks — rebased onto latest main and bumped the kache@0.16.0 workflow count from 5 to 6 in scripts/ci-workflow-policy.test.mjs. The revision-suffixed key and default-branch Save assertions already matched; node --test scripts/ci-workflow-policy.test.mjs is green locally.