Security: Windows runtime bundles HDF5 1.12.0, netCDF-C 4.8.1, CFITSIO 3.49 and HDF4 4.2.13 from the GisInternals SDK; build them from vcpkg as Linux/macOS already do, or disable the drivers #246

MaxRev.Gdal.WindowsRuntime.Minimal (3.13.2.549 and 3.13.3.563, byte-identical files) ships four format libraries as frozen prebuilt copies from the GisInternals release-1930 SDK, none with a Windows version resource:

• hdf5.dll: HDF5 1.12.0 (2020; embedded "HDF5 library version: 1.12.0"). NVD lists 65 entries for this version, including a dozen CVSS 9.8 file-parsing bugs (the CVE-2024-29157 family). gdal.dll imports 120 symbols from it.
• netcdf.dll: netCDF-C 4.8.1 (build string "4.8.1 of Nov 29 2024"), which itself links HDF5. CVE-2026-86095 (7.8). gdal.dll imports 150 symbols.
• cfitsio.dll: CFITSIO 3.49. CVE-2018-3848 and CVE-2018-3849 (8.8). gdal.dll imports 33 symbols.
• hdf.dll / mfhdf.dll (HDF4 4.2.13) with the xdr.dll shim and szip.dll. gdal.dll imports 45 and 23 symbols.

Because the imports are static, none of the files can be removed from an installation without breaking gdal.dll. On Linux and macOS the same package already builds hdf5, netcdf-c and cfitsio from vcpkg (shared/vcpkg.json, linux-dynamic / osx-dynamic); Windows is the only platform still on the SDK copies, exactly the situation #242 fixed for libpq and #245 covers for libmysql. A certification vulnerability report for our product lists these files and asks us to "update or remove any files that have vulnerabilities or CVEs".

To Reproduce

1. nuget install MaxRev.Gdal.WindowsRuntime.Minimal -Version 3.13.3.563
2. runtimes/win-x64/native/hdf5.dll, netcdf.dll, cfitsio.dll, hdf.dll, mfhdf.dll: no version resource; the version strings above are embedded in the binaries (strings / findstr).
3. dumpbin /imports runtimes/win-x64/native/gdal.dll shows all of them as static imports.

Expected behavior

1. Add cfitsio, hdf5 and netcdf-c to the windows-dynamic feature (parity with linux-dynamic / osx-dynamic), point GDAL's find modules at $env:VCPKG_INSTALLED in win/partials.psm1 the way fix(win): build libpq from vcpkg instead of the GisInternals SDK #242 did for PostgreSQL, and assert the packaged DLLs match the vcpkg build byte-for-byte. Current vcpkg baseline: hdf5 2.2.0, netcdf-c 4.9.3, cfitsio 4.7.0 (netcdf-c pulls hdf5, so the two move together).
2. HDF4 has no vcpkg port. Either build GDAL on Windows with -DGDAL_USE_HDF4=OFF (the HDF4 driver would be Windows-unavailable, which is acceptable to us) or keep the SDK copy and document it; we would prefer OFF, since it also removes xdr.dll and szip.dll from the payload.

Environment

• Package: MaxRev.Gdal.WindowsRuntime.Minimal 3.13.3.563 (same files in 3.13.2.549)
• OS: Windows 11 x64, .NET 10

Additional context
We do not read HDF4, HDF5, netCDF or FITS data; as an interim mitigation our application deregisters those GDAL drivers at start-up through GDAL_SKIP, so the parsers are unreachable, but the files still ship and still get flagged. An upstream rebuild removes the finding for every Windows user of the package. Happy to test a pre-release package or to open a PR along the lines of #242 for whichever option you prefer.