CI: speed up the NanoVDB Windows job

[swahtz]

The windows-nanovdb job spends ~37 of its ~52 minutes installing dependencies from scratch on every run (e.g. this run: install_cuda 13 min, vcpkg install 24 min). This PR:

• Enables vcpkg's GitHub Actions binary caching (x-gha) so dependency builds are reused across runs instead of compiled from source (~24 min → ~1-2 min on a cache hit). A github-script step exports the Actions cache URL/token, which are only visible to JavaScript actions.
• Caches the CUDA toolkit directory and skips the NVIDIA network installer on a hit, restoring the environment variables and the Visual Studio build customizations the installer would have set up (~13 min → ~1 min).
• Trims the vcpkg package list to what this job's components actually need, dropping openexr, cppunit, glfw3, glew and libpng (NanoVDB has no glfw/glew usage).

ci/install_windows.ps1 gains an optional -Packages parameter that defaults to the existing full list, so build.yml and weekly.yml are unaffected.

Notes:

• The first run after merge is no faster (cold caches, plus cache-save time); steady state should be roughly 52 min → ~20 min, with the build step becoming the long pole (sccache would be a follow-up).
• Caches invalidate when the runner image updates vcpkg's port baseline, so occasional slow runs are expected.

🤖 Generated with Claude Code

[harrism]

This is awesome. The Windows CI is slow. I think windows runners tend to be more expensive than Linux as well, so a good savings.

[danrbailey]

Hi @swahtz, I just wanted to mention that we use GHA caches in a slightly unusual way on this project. We have a CI job that runs once a week and caches the latest Houdini production installation and then this gets re-used on each per-commit CI run. Then the following week it runs again and potentially picks up a later installation. If these caches get eliminated, the weekly CI needs to be run by hand to re-populate them so the per-commit CI can succeed. This is also done as an airgap to prevent the API access keys leaking into PRs submitted against the repo.

The caches are prefixed "vdb-v5-houdini*" under https://github.com/AcademySoftwareFoundation/openvdb/actions/caches. We also currently use GHA caches for ccache.

GHA cache space has a limit of 10GB (although I understand it is also an option to pay to extend this) and they get evicted based on most-recently used logic. Our Houdini caches typically fall well within that 10GB limit, so I expect your new caching will be fine. I wouldn't object to rolling this out and then discussing what to do if we start routinely eliminating the Houdini caches in practice, just letting you know about this extra consideration.

How much data do you expect this to be and if it's not a lot, could we potentially share data between these jobs and the other Windows CI such as build and weekly?