Rebuild for HDF5 2 with CMake compatibility

[wolfv]

This refreshes and supersedes #436 on top of current main.

VTK 9.6.2 expects HDF5_IS_PARALLEL from the external HDF5 CMake package. HDF5 2 instead exports the equivalent HDF5_PROVIDES_PARALLEL, causing configuration to fail before compilation. The source patch loads the external package config and maps the HDF5 2 variable to the name expected by VTK's third-party machinery while preserving compatibility with HDF5 1.14.

The feedstock is rendered for both HDF5 1.14.6 and HDF5 2 during the migration.

This currently blocks downstream migration combinations such as:

• VTK 9.6.2 + Python 3.12 + HDF5 2
• OpenCV 4.13 *_614 (HDF5 2 / Protobuf 7)
• RoboStack's ROS Jazzy full environment on Windows and macOS arm64

I independently reproduced the solver conflict: current VTK builds require hdf5 >=1.14.6,<1.14.7, while migrated OpenCV builds require hdf5 >=2.1,<3.

Upstream issue: https://gitlab.kitware.com/vtk/vtk/-/work_items/20014
Previous migration PR: #436
Downstream investigation: RoboStack/ros-jazzy#263 (comment)

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

• ℹ️ 'Free Disk Space' is deprecated.
  Deprecated. Use workflow_settings.free_disk_space instead.
  This setting accepts a boolean or a list containing apt, cache,
  and docker. When set to true, only apt and cache are cleaned
  up. Set it to the full list to clean up all components.

The replacement setting uses the values skip, quick, and max
instead; the values accepted by this deprecated setting are not valid
for the replacement setting.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/31386280311. Examine the logs at this URL for more detail.}

[wolfv]

The first CI pass confirmed that the build reaches and finds HDF5 2.2, but my initial compatibility mapping ran before VTK's third-party helper called find_package, so HDF5_PROVIDES_PARALLEL was not yet available.

Commit c826534 moves the compatibility mapping into vtk_module_third_party_external, immediately after package discovery and before USE_VARIABLES validation. This is also a more accurate source-level fix: it translates HDF5 2's detected HDF5_PROVIDES_PARALLEL value rather than hardcoding serial mode.

[wolfv]

The source compatibility fix worked: HDF5 2 VTK builds completed. The remaining failures came from building both HDF5 variants sequentially in one CI job while sharing vtk_ffmpeg_dir_${PKG_VERSION}_${PY_VER}. The first vtk-io-ffmpeg output moved the staged module, leaving the second variant empty and causing ModuleNotFoundError during its test.

Commit 87056a3 includes the HDF5 variant in the shared staging directory on Unix and Windows, keeping the two output builds isolated.

[wolfv]

The latest CI pass validates the fix across Linux, Linux aarch64, Windows, macOS arm64, and three of five macOS x86_64 Python variants. The two remaining macOS x86_64 failures are infrastructure/runtime-only:

• Python 3.13 failed before setup because pixi.sh DNS resolution failed.
• Python 3.11 was canceled at the Azure six-hour job limit while still compiling; the same source and both HDF5 variants passed for Python 3.10, 3.12, and 3.14 on osx-64.

Marking ready for review; there are no remaining source, packaging, or test failures in this pass.