fix(ci): STX C++ integration job trusts a partially-deleted CMake cache

[kovtcharov]

Blocks every cpp/** PR in milestone #63. All three open Wave 1 PRs (#2807, #2809, #2816) fail the same check, C++ Integration Tests (STX), and none of them for a reason related to their changes — the build never reaches compilation.

Symptom

CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
C:/Windows/Temp/cmake/cmake-3.31.4-windows-x86_64/share/cmake-3.31
CMake Error: Error executing cmake::LoadCache(). Aborting.

Root cause

.github/workflows/build_cpp.yml:196-221. The job caches CMake under $env:TEMP and decides whether to re-download with:

$cmakeCached = "$env:TEMP\cmake\cmake-${cmakeVer}-windows-x86_64\bin"
...
} elseif (Test-Path "$cmakeCached\cmake.exe") {
    echo "$cmakeCached" >> $env:GITHUB_PATH
}
if (-not (Get-Command cmake ...) -and -not (Test-Path "$cmakeCached\cmake.exe")) {
    # download + Expand-Archive
}

The validity check tests the wrong artifact. It confirms bin/cmake.exe exists but never confirms share/cmake-3.31/Modules/ — which is what CMAKE_ROOT actually resolves to. On this self-hosted runner Windows Temp cleanup (or a partial extraction) removed share/ and left bin/. The guard therefore sees a healthy cache, skips the re-download, prepends a broken CMake to PATH, and every subsequent run fails identically until somebody clears the temp directory by hand.

This is the failure mode CLAUDE.md's no-silent-fallbacks rule exists for: a cache-validity shortcut that silently substitutes a broken tool instead of failing loudly or repairing itself.

Fix

1. Validate what you actually depend on. Replace the cmake.exe-only check with a real probe — assert share/cmake-<major.minor>/Modules exists, and/or run cmake --version and require exit 0. If either fails, treat the cache as absent and re-extract.
2. Make re-extraction self-healing — remove the stale directory before Expand-Archive so a partial extraction cannot persist across runs.
3. Do not cache into $env:TEMP on a self-hosted runner. Temp is subject to OS cleanup that will keep re-creating this. Use a runner-persistent tools directory the job controls.
4. Consider lukka/get-cmake or an equivalent pinned action rather than hand-rolled download/extract logic.

Acceptance

• With share/ deleted but bin/cmake.exe present, the job detects the broken cache and repairs it instead of failing.
• The three blocked PRs (feat(cpp): gaia::VectorIndex — flat vector index with persistence #2807, feat(cpp): gaia::HttpClient — a general HTTP client abstraction #2809, feat(cpp): SQLite integration and gaia::Database #2816) go green on this check without changes to their own diffs.
• A comment in the workflow states why the validity check probes Modules/ — otherwise the next person simplifies it back to Test-Path cmake.exe.

Found during the milestone #63 orchestration sweep. Plan: docs/plans/cpp-framework-parity.md

[kovtcharov]

Correction: it is not one broken runner, it is a pool with one bad machine

Earlier I reported the STX runner had "recovered" because #2820 went green. That was wrong, and the real picture makes this fix more important rather than less.

The STX label maps to a pool of at least two machines, and the outcome tracks the machine, not the change:

PR	Runner	STX
#2820	XSJ-AIMLAB-STXP	success
#2807	xsj-aimlab-stxp-08	failure — Could not find CMAKE_ROOT

#2820 did not pass because anything was repaired; it passed because it happened to land on the healthy box. Re-running #2807, #2809, #2816 and #2821 put them straight back on the broken one.

Two consequences:

1. A manual temp clear is not a fix. It repairs one machine until the next Temp cleanup, and it does nothing for any other machine in the pool that is already in this state or gets there later. The self-healing validation in this issue is the actual remedy.
2. This failure is machine-dependent, so it will read as flaky. A PR can go green, get re-run, and go red with an identical diff. That is worth a comment in the workflow — otherwise the next person to see an intermittent STX failure will assume a race in the tests rather than a poisoned tool cache.

Please also confirm the fix repairs a machine that is already poisoned, not merely that it prevents a healthy one from becoming so — xsj-aimlab-stxp-08 is a live reproduction of the bad state.