ci(windows): add Windows MSVC CI jobs

[pimlock]

Summary

Add Windows MSVC CI jobs to validate Windows-supported Rust crates on pull requests and keep the Windows build cache warm on main. Build release binaries after merges to main, without publishing them.

Related Issue

No issue required: localized CI infrastructure work following #2496.

Changes

• add a pull-request job that runs strict Clippy on Windows-sensitive crates and tests the supported Rust workspace on windows-2025
• add a cache-seeding job on main that runs the same lint and test workload to keep pull-request caches warm
• add a dependent job on main that builds Windows release binaries without publishing them
• use prebuilt Z3 archives instead of compiling Z3 from source
• cache Cargo target artifacts and use the GitHub Actions sccache backend
• scope Unix-only and test-only Rust code so Windows Clippy passes with -D warnings and no blanket warning allowances
• document the Windows CI scope and cache behavior
• enable the OpenTelemetry in-memory exporter explicitly for tests

Testing

• mise run pre-commit passes
• cargo test -p openshell-otel passes
• target-cache and sccache experiments completed on windows-2025
• fully warm sccache achieved 62/62 compiler-cache hits with no errors
• hosted Windows strict Clippy and tests pass
• Branch Checks, E2E, Helm, and required aggregate gates pass
• E2E tests added/updated (not applicable; CI-only change)

Detailed timing and cache measurements are recorded in the PR comments.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[pimlock]

Windows MSVC cache experiments

I ran the hosted windows-2025 workflow repeatedly while changing one major cache/build variable at a time. Times below are end-to-end workflow/job times and can vary slightly with runner setup and GitHub cache transfer latency.

Configuration	Cache state	Runtime	Notes
Original workflow / bundled Z3	effectively cold	~75m48s–78m22s	Baseline; Z3 compiled from source and the Rust target tree was not providing a useful warm reuse path. run, repeat
Cargo target cache / bundled Z3	cold	~75m16s	Populated the target archive. run
Cargo target cache / bundled Z3	warm	~18m39s	Large improvement; target artifacts were the most effective cache layer. run
sccache only / bundled Z3	cold	~80m47s	Target cache disabled to isolate sccache. Remote writes made the cold run slower. run
sccache only / bundled Z3	warm	~67m55s	1,157 hits / 122 misses (90.46% hit rate), but linking, non-cacheable crate types, Z3 work, and remote reads left total time high. run
Cargo target cache + prebuilt Z3	cold	~37m28s	z3-sys downloaded the pinned official prebuilt Z3 archive instead of compiling Z3 via CMake/MSBuild. run
Cargo target cache + prebuilt Z3	warm	~16m24s	Check 1m14s, release build 6m36s, tests 4m46s, focused test 2m12s; target restore ~58s. run
Target cache + prebuilt Z3 + sccache	target warm, sccache cold	~17m09s	62 misses, 62 successful writes, 0 errors; cache writes took 32.6s. run
Target cache + prebuilt Z3 + sccache	both warm	~15m45s	62/62 sccache hits, 0 misses/errors; check 1m07s, release build 5m19s, tests 5m06s, focused test 2m25s. run
Warm hybrid cache, redundant focused test removed	both warm	~12m33s	Check 1m01s, release build 5m07s, full tests 4m58s. The full suite already includes the Windows unsupported-driver contract test. run

Conclusions

• Cargo target caching was the largest win: roughly 75 minutes cold to roughly 19 minutes warm with bundled Z3.
• Prebuilt Z3 materially improved cold builds: the cold target-cache run dropped from roughly 75 minutes to roughly 37 minutes.
• sccache alone was not competitive, despite a high hit rate. It does not cache final linking or several Rust crate types, and GitHub remote reads still cost time.
• sccache is useful as a secondary layer on top of the target cache: it reduced the warm release build from roughly 6m36s to 5m19s and produced a clean 100% hit rate for the 62 cacheable compiler requests in the measured run.
• The best measured stack is Cargo target cache + prebuilt Z3 + sccache, with the redundant focused test removed.
• The PR/main split is intended to keep PR validation focused on Windows Clippy + Rust tests, run that same workload on main to warm the exact PR cache namespaces, and build (but not upload/publish) release binaries after the seed succeeds.

Current validation note

The earlier single-job hybrid workflow is proven by the successful runs above. The new multi-job split currently receives an opaque GitHub startup_failure before any job is created, on both manual dispatch and the PR mirror. actionlint reports the workflow as valid, and a temporary ref at the last known-good commit starts normally, so I am continuing to isolate the workflow-graph difference before treating the split as ready.

[pimlock]

Validation update: the opaque pre-job startup_failure was isolated to jdx/mise-action v4.2.4 on windows-2025. Restoring the previously measured v4.2.0 pin fixes workflow startup. The PR mirror is now running PR lint and test (x64), and a manual dispatch is independently running Seed cache (x64) followed by Build binaries (x64). The newer Swatinem/rust-cache v2.9.2 pin remains in place.