ci(windows): pre-populate msys2 pkgconf 1~2.2.0-1 for vcpkg 2024.10.21

[Fedr]

What

Adds one file under thirdparty/vcpkg/downloads/:

msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst
SHA512  eb6ba49d56b0edc4f605ad896ac9deb2202c853c821f1c28a26e3c71a5083e893c8697d174b141da9dc6561620ea218166bd041664d54a0ab51b93bad246ed7a

This is the exact file that the Windows vcpkg 2024.10.21 matrix entry tries to fetch inside vcpkg_fixup_pkgconfig() and currently 404s on every msys2 mirror. The SHA512 matches what vcpkg pins in scripts/cmake/vcpkg_find_acquire_program(PKGCONFIG).cmake.

How the mechanism works

thirdparty/install.bat already does this before the first vcpkg install:

if exist "%~dp0vcpkg\downloads\" (
    xcopy "%~dp0vcpkg\downloads\*" "!vcpkg_path!downloads" /Y /E 2>/dev/null
)

So any file placed under thirdparty/vcpkg/downloads/ ends up in C:\vcpkg\downloads\ at install time. When vcpkg later needs to acquire a package by URL, vcpkg_download_distfile() checks the local downloads directory first: if a file with the expected filename exists and its SHA512 matches, the network fetch is skipped entirely.

Same mechanism is already in use — there are 7 pre-committed msys-*.pkg.tar.* files in that directory today, put there for the same reason (older msys2 pins that have been pruned from mirrors).

Scope

• Affects: Windows msvc-2019 Release CMake 2024.10.21 matrix entry. Fresh vcpkg builds of blosc, freetype, libharu, and any other port that calls vcpkg_fixup_pkgconfig() will now succeed instead of hitting the 404.
• Unaffected: msvc-2022 Debug MSBuild 2026.03.18 and msvc-2022 Release CMake 2026.03.18 matrix entries. Those use vcpkg 2026.03.18, which pins a completely different URL (pkgconf-2.5.1-1 from the msys/x86_64/ directory, still live on mirrors).
• No Linux / macOS / emscripten impact — those don't use msys2.

Verification I did before committing

1. Ran sha512sum against the file and confirmed it's byte-identical to the hash vcpkg pins.
2. Confirmed the filename matches what vcpkg writes to its local downloads dir (msys2--prefixed, not msys-; vcpkg changed the prefix convention at some point, which is why the pre-existing files in the folder use the old naming).
3. Read vcpkg 2024.10.21's vcpkg_find_acquire_program(PKGCONFIG).cmake to confirm this is the exact URL/hash pair that the failing build stack would reach.
4. Read vcpkg 2026.03.18's equivalent to confirm it targets a different URL entirely — this PR does not help or hurt that path.

Limitations / future work

• This is a point fix for one specific pin. If vcpkg bumps to a version that changes the pin again, a new pre-populated file will be needed (or the pin will land on a URL that's still live).
• A cleaner long-term fix is to bump matrix.vcpkg-version in build-test-windows.yml off 2024.10.21 to a release whose pkgconf pin is still on msys2 mirrors. That's a larger change because the 2024.10.21 entry is wired to msvc-2019 and possibly to specific downstream-compatibility expectations; out of scope here.
• If other matrix entries later start hitting similar 404s on newly-retired msys2 pins, the same pattern — commit the file, same directory — applies.