ci: stop re-downloading CMake/Ninja on every Windows run

lukka/get-cmake@latest re-fetched and re-extracted CMake + Ninja on
every single Windows CI run. Its own cache (routed through this
act_runner's built-in cache server) reported "Cloud cache miss" on
every run, even one immediately after a run that logged a successful
save under the exact same key -- an incompatibility between its
bundled cache client and this act_runner's cache-server implementation,
not a config gap. Separately and more importantly: the archive
extraction step alone measured ~7.5 minutes for a 45MB zip on this VM,
consistent with Defender real-time scanning rather than raw disk I/O.
Together this was the dominant cost of every Windows CI run.

CMake 4.4.2 and Ninja 1.12.1 are now installed once, directly on the
winvm-builder VM's system PATH (C:\BuildTools\cmake, C:\BuildTools\
ninja), sidestepping the third-party action's cache entirely rather
than debugging its internals further. Both Windows jobs now just
verify cmake/ninja are present and fail loudly if not, instead of
silently falling back to a slow reinstall. Full detail, including how
to redo this if the VM is ever rebuilt, is in README's new "Windows
runner: persistent build tools" section -- this is VM state, not
something git reproduces.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE

README.md

@@ -281,6 +281,51 @@ and a permanently red CI teaches people to ignore CI. **Do not remove the
 warning:** a green job that quietly stopped building the plugin is worse than
 a red one.
 
+### Windows runner: persistent build tools (2026-09-07)
+
+`winvm-builder`'s Windows job used to install its own CMake + Ninja on every
+single run via `uses: lukka/get-cmake@latest`. That action has its own
+caching (routed through this act_runner's built-in cache server, the same
+mechanism `.deps/`'s `actions/cache` step above relies on and that one does
+work) but it never hit: every run logged `Cloud cache miss` against the same
+cache key, even immediately after a run that logged a successful save under
+that exact key -- some incompatibility between `lukka/get-cmake`'s bundled
+cache client and this act_runner's cache-server implementation, not
+"caching isn't configured." Separately, and the larger cost: the archive
+extraction step alone measured **~7.5 minutes** for a 45MB zip on this VM
+(13:11:14 to 13:18:48 in one captured run) -- consistent with Windows
+Defender real-time-scanning every extracted file, not raw disk I/O, though
+that specific cause is not confirmed. Together this was the dominant cost of
+every Windows CI run, cold cache or not.
+
+Fix: CMake 4.4.2 and Ninja 1.12.1 are now installed once, directly on the
+`winvm-builder` VM (Proxmox VMID 110, host pve4/192.168.1.145), not fetched
+per-run:
+
+- `C:\BuildTools\cmake\` (from
+  `cmake-4.4.2-windows-x86_64.zip`, Kitware's GitHub releases) and
+  `C:\BuildTools\ninja\` (from `ninja-win.zip`, `ninja-build/ninja` v1.12.1
+  release) — plain `Expand-Archive` drops, nothing installed via an
+  installer/MSI.
+- Both added to the **Machine**-level `PATH`
+  (`[Environment]::SetEnvironmentVariable('PATH', ..., 'Machine')`, not
+  `setx`, which silently truncates a `PATH` this long).
+- The `GiteaRunner-winvm-builder` scheduled task (`C:\gitea-runner\
+  gitea-runner.exe daemon`, runs as SYSTEM) was stopped and restarted after
+  the `PATH` change — a already-running process does not pick up an updated
+  Machine environment variable, only processes started after the change do,
+  and every CI job is a child process of this one long-running daemon.
+
+Both workflows' Windows jobs now just run `cmake --version` / `ninja
+--version` as a "Verify build dependencies" step and fail loudly if either
+is missing, instead of silently falling back to the slow per-run install.
+
+**This is VM state, not something `git clone` reproduces.** If
+`winvm-builder` is ever rebuilt or reimaged, redo the three steps above
+(download+extract both zips under `C:\BuildTools\`, extend the Machine
+`PATH`, restart the scheduled task) before expecting Windows CI to pass
+again — there is nothing in this repo that does it automatically.
+
 ### Where the macOS bootstrap actually got to
 
 Six CI iterations, each fixing a real failure visible in the logs: