ci(windows): hash overlay/triplet/requirements into vcpkg cache key, plus related fixes

[Fedr]

Problem

The setup-vcpkg-windows composite action keys the vcpkg cache only on vcpkg-version + vcpkg-triplet:

key: vcpkg-cache-${{ inputs.vcpkg-version }}-${{ inputs.vcpkg-triplet }}

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

• thirdparty/vcpkg/ports/** — MeshLib's overlay ports (custom opencascade-minimal, laz-perf, openctm, clip, …)
• thirdparty/vcpkg/triplets/<triplet>.cmake — the active custom triplet 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. Any PR that introduces a new overlay port, edits an existing one, or tweaks the triplet won't actually exercise its change on Windows until the cache happens to be rebuilt for an unrelated reason.

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

In setup-vcpkg-windows/action.yml, add a Compute Vcpkg Cache Key step that hashes the relevant paths and exposes the result as VCPKG_CACHE_KEY:

- name: Compute Vcpkg Cache Key
  shell: bash
  run: |
    triplet_file="thirdparty/vcpkg/triplets/${{ inputs.vcpkg-triplet }}.cmake"
    echo "Triplet file: $triplet_file"
    test -f "$triplet_file" || { echo "::error::Triplet file not found: $triplet_file"; exit 1; }
    echo "VCPKG_CACHE_KEY=vcpkg-cache-${{ inputs.vcpkg-version }}-${{ inputs.vcpkg-triplet }}-${{ hashFiles('thirdparty/vcpkg/ports/**', format('thirdparty/vcpkg/triplets/{0}.cmake', inputs.vcpkg-triplet), 'requirements/windows.txt', 'thirdparty/install.bat') }}" >> "$GITHUB_ENV"

- name: Restore Vcpkg Cache
  uses: actions/cache@v5
  with:
    key: ${{ env.VCPKG_CACHE_KEY }}
    ...

Only the active triplet file is hashed (via format()), not all files under thirdparty/vcpkg/triplets/ — changes to a triplet that this job doesn't use should not bust its cache. The compute step also test -fs the resolved triplet path and fails fast with a ::error:: annotation if missing — a misconfigured vcpkg-triplet would otherwise silently feed an empty string into hashFiles.

All three callers of setup-vcpkg-windows (build-test-windows.yml, pip-build.yml windows-pip-build, update-win-version.yml) inherit the new behavior automatically. Steady-state unchanged: the same branch run twice in a row still hits the cache.

Also in this PR

While auditing the cache flow a few related issues surfaced and got fixed in the same change:

• VS2019 toolset edit moved into the action. Previously inline in build-test-windows.yml (as a separate step run before the action call). Now an enable-vs2019-toolset input on the action; gated on matrix.cxx_compiler == 'msvc-2019' from the build-test-windows caller and pinned to 'true' from update-win-version.yml. Keeps the v142-marker uncomment hashed into the cache key.
• prepare-image matrix expanded. The windows-vcpkg-build-upload matrix only built vs2019 + x64-windows-meshlib-iterator-debug, leaving s3://vcpkg-export/2024-10-18/x64-windows-meshlib/ empty for builds against the regular triplet. Added a third row (vs2019 + x64-windows-meshlib) and the matching Enable VS2019 toolset for vcpkg step (gated on matrix.vs == 'vs2019'), so msvc-2019 jobs now find pre-built v142 ABI binaries in S3 instead of source-building opencascade for ~40 min on every cold lookup.
• reuse-vcpkg input removed. Was a no-op for every caller after update-win-version.yml stopped passing it. Action now always runs clean → fetch → checkout → bootstrap → integrate. Skipping bootstrap was unsound: the runner image's pre-installed vcpkg.exe is newer than tag 2024.10.21 and reads scripts/vcpkg-tools.json, a file that the older source tree doesn't ship — caused read_contents failed with 2 (no such file or directory) on the update-win-version path.
• Faster git fetch + cleaner log. Skip git fetch entirely when the requested vcpkg ref is already in the local clone (the windows-2025 runner image ships microsoft/vcpkg with all old tags); fall back to git fetch --depth=1 origin <tag> otherwise — only the requested ref, not all of master + new tags. Adds --quiet to git clean / fetch / checkout to suppress the ~900 lines of Updating files: NN% progress on the master → 2024.10.21 working-tree rewrite.

Cost

First run after this lands does a one-time vcpkg rebuild (~20 min per (vcpkg-version, triplet, hashFiles) combination, runs in parallel) to populate actions/cache under the new key shape. Subsequent runs hit the cache as before. Every future overlay-affecting PR pays a one-time rebuild on first push, which is the correct behavior.

Set up vcpkg step on a steady-state cache-hit run, comparing equivalent matrix slots against master:

matrix slot	master	this PR	Δ
msvc-2019 Release CMake, x64-windows-meshlib	3:29	2:48	−0:41
msvc-2019 Debug CMake, iterator-debug	2:49	2:23	−0:26
msvc-2022 Debug MSBuild	3:00	2:28	−0:32
msvc-2022 Release CMake	2:38	3:06	+0:28

Three of four slots improve by ~25–40 s; the fourth is within normal CI variance for cache-restore + S3 throughput.

Not in this PR

Same problem may or may not exist on other cached steps (CUDA cache, test-data cache). Only the vcpkg cache is audited here; no similar-shaped problems found on other caches in passing, but no exhaustive review.

Rollback

The change is contained to four files: .github/actions/setup-vcpkg-windows/action.yml, .github/workflows/build-test-windows.yml, .github/workflows/prepare-images.yml, .github/workflows/update-win-version.yml. Revert restores the old key shape; cache entries under the new key become orphans and expire naturally.