ci(windows): bust vcpkg cache on overlay/triplet/requirements changes

[Fedr]

Problem

The Windows vcpkg cache in .github/workflows/build-test-windows.yml is keyed only by matrix.vcpkg-version:

key: vcpkg-cache-${{ matrix.vcpkg-version }}

Changes to any of these don't invalidate the cache:

• thirdparty/vcpkg/ports/** — MeshLib's overlay ports (e.g. custom opencascade-minimal, laz-perf, openctm, clip, and as of #5932 a zlib → zlib-ng-compat override)
• thirdparty/vcpkg/triplets/** — custom triplets passed via --overlay-triplets
• requirements/windows.txt — the package list install.bat feeds to vcpkg
• thirdparty/install.bat — changes to how vcpkg is invoked

A pre-built C:\vcpkg\installed\ tree gets restored verbatim; install.bat's vcpkg install ... step sees every transitively-required port as already installed and completes in a few milliseconds without consulting overlay ports.

Evidence from PR #5932's Windows run

From windows-build-test (msvc-2022, Release, CMake, …) on run 24629386911:

12:46:32  Cache hit for: vcpkg-cache-2026.03.18
12:48:11  Cache restored from key: vcpkg-cache-2026.03.18
          ...
          The following packages are already installed:
              boost-*, freetype[core,zlib,...], libzip[core,...], tiff[zip,...], ...
          Total install time: 3.57 ms

zlib doesn't even appear in the already-installed list (it's a transitive dep). vcpkg saw every port satisfied by the cached tree — which had been populated on master before PR #5932's overlay existed — and declared the install plan done. The overlay was detected (Using overlay: D:\a\MeshLib\MeshLib\thirdparty\vcpkg\ports appears in the log) but never used because nothing needed installing.

Compression benchmark numbers, for reference (from the MRMesh.CompressSphereToZip test in PR #5933):

	master (gzip)	PR #5932 branch (zlib-ng)	Δ
linux-vcpkg Release x64 Clang	2441 ms	1336 ms	−45.3% ✓
linux-vcpkg Release arm64 Clang	1467 ms	860 ms	−41.4% ✓
windows-build-test Release CMake msvc-2022	2182 ms	2115 ms	−3.1% (noise)
windows-build-test Release CMake msvc-2019	2163 ms	2210 ms	+2.2% (noise)

Linux-vcpkg rebuilds vcpkg from scratch inside the prepare-image / linux-vcpkg-build-upload Docker image each time, so it doesn't hit this cache-key problem. Windows did.

Fix

Expand the cache key to hash the relevant paths:

key: vcpkg-cache-${{ matrix.vcpkg-version }}-${{ hashFiles('thirdparty/vcpkg/ports/**', 'thirdparty/vcpkg/triplets/**', 'requirements/windows.txt', 'thirdparty/install.bat') }}

Any change to overlay ports, triplets, the package list, or the install script busts the cache and forces a fresh install. Steady-state unchanged: same branch twice in a row still hits the cache.

Cost

First run after this lands does the full Windows vcpkg install (~20 min, one-time). Subsequent same-branch runs hit the cache again as before. Every future overlay-affecting PR pays a one-time rebuild, which is the correct behavior.

Not in this PR

• Rerunning ci(vcpkg): overlay zlib port with zlib-ng built in compat mode #5932 measurement on Windows. That's a follow-up once this merges: the next CI run on ci(vcpkg): overlay zlib port with zlib-ng built in compat mode #5932's branch after this lands will finally exercise the zlib-ng path on Windows and we can see if the ~40-45% speedup replicates there.
• Same problem may or may not exist on other cached steps (CUDA cache, test-data cache). I only audited the vcpkg cache because that's where ci(vcpkg): overlay zlib port with zlib-ng built in compat mode #5932's symptom pointed; didn't find similar-shaped problems on other caches while I was in there, but didn't do an exhaustive review.

Rollback

Single-file revert of .github/workflows/build-test-windows.yml restores the old cache key. No lingering state — the cache entries under the new key just become orphans that expire naturally.