[Neonforge98]

Problem

The v2.0.1 release (run 34867810344) failed in Build & Release (Windows x64):

error[E0432]: unresolved import `super::process_tree_exists`
  --> crates\agent-core\src\core\tools\impls\coding\exec\registry\session_lifecycle.rs:18:37

process_tree_exists is #[cfg(unix)] in registry.rs, but the new session_lifecycle module imported it unconditionally. The v2.0.0 release failed the same way on a different Windows-only unresolved import (app_platform::CommandCreationFlagsExt, fixed in #1795).

Root cause of the recurrence: the Rust (clippy) CI job runs on macos-latest only. The compiler configures the #[cfg(windows)] arm out on macOS, so a Windows-only cfg split is invisible to every PR check and surfaces for the first time on the release tag build.

Solution

1. Fix the compile error. session_lifecycle.rs now imports process_tree_exists under #[cfg(unix)] and routes the per-platform probe through a small shell_process_tree_gone helper with a Unix and a Windows arm, so the call site carries no platform attributes.
2. Clear every Windows-only warning so a warnings-denied Windows clippy run is green. These were all latent cfg mismatches (imports, locals, or helpers used only in a macOS/Unix arm): browser cookie sources, terminal agent-tool and process inspect, key-vault cursor cache permissions, agent-core MCP config, perf-utils app-memory (lib and tests), app-window traffic lights, orgtrack-core copilot history tests, integrations gh detection, system-services port scanner.
3. Add a Rust (clippy, Windows) CI job in ci.yml (same rust_required gate, windows-latest, cargo clippy --workspace --all-targets -- -D warnings). Compile-only: the workspace test suite still runs on macOS; this job's purpose is to prove the release target builds before a tag is pushed.
4. Add a Windows cache warmer to warm-rust-cache.yml under the matching ci-windows key so PR runs start warm.

Potential risks

• The new Windows job is not yet in branch protection's required checks. Until it is added there, it reports but does not block merges. Please add Rust (clippy, Windows) to the required checks after this merges.
• Windows runner time is added to Rust-touching PRs. The change-scope gate skips it for frontend-only diffs, and the warmer keeps it off a cold start.
• The cfg gating changes are compile-time only and change no runtime behavior on any platform. macOS clippy was not run locally (Windows machine); the macOS CI job on this PR is the check for that.

Verification

• Local, Windows 11, host x86_64-pc-windows-msvc:
  • cargo check --workspace --all-targets on develop reproduced the release error exactly (E0432 in session_lifecycle.rs).
  • cargo clippy --workspace --all-targets -- -D warnings after the fix: exit 0, no diagnostics (the same command the new CI job runs).
  • cargo test for the touched crates (app_window, perf_utils, orgtrack_core, system_services, integrations, key_vault, browser, terminal, agent_core):
    • app_window, perf_utils, orgtrack_core, system_services, browser, terminal: all pass.
    • integrations: 2 pre-existing Windows failures (computer_use_lock::tests::is_process_running_self, cli_binary_resolver::tests::preferred_paths_reuse_executable_validation_before_normal_resolution). Both reproduce identically on unmodified develop; neither file is touched here.
    • key_vault: 2 failures in untouched files (auto_detect::suggestions, commands::registry), both environment-dependent path/PATH lookups.
    • agent_core: the test binary exits with STATUS_ENTRYPOINT_NOT_FOUND on this machine (a DLL loader error, not a test assertion). It cannot be compared against develop, where the crate's test target does not compile on Windows at all. Clippy builds the same test target cleanly.
  • This is why the new CI job is clippy-only: Windows test parity is a separate piece of work.
• Not run: cargo test --workspace on Windows, macOS clippy and tests. The macOS CI job on this PR covers the latter.