GHA: build ITKVtkGlue against system-package VTK (HDF5 + Qt5 reconciliation)

[hjmjohnson]

Track the engineering work needed to actually build Module_ITKVtkGlue=ON in GitHub Actions against system-package VTK (apt's libvtk9-dev on Ubuntu, Homebrew's vtk on macOS). Spun out of #6144 after a first-cut attempt surfaced two real, pre-existing surface issues that are out of scope for the floor-bump PR.

The motivation: ITK 6 raises VtkGlue's VTK floor to 9.1 (#6144) and removes the legacy vtk_module_config shim. Currently zero GHA jobs build ITKVtkGlue, so the post-shim code paths get no GHA coverage. Adding a system-VTK install step looks like a one-page YAML edit on paper but hits the issues below.

Failure 1 — HDF5 target collision on macOS

CMake Error at /opt/homebrew/lib/cmake/hdf5/hdf5_static-targets.cmake:42 (message):
  Some (but not all) targets in this export set were already defined.

Call Stack (most recent call first):
  /opt/homebrew/opt/vtk/lib/cmake/vtk-9.5/patches/99/FindHDF5.cmake:501 (find_package)
  /opt/homebrew/opt/vtk/lib/cmake/vtk-9.5/vtk-config.cmake:171 (include)
  Modules/Bridge/VtkGlue/itk-module-init.cmake:17 (find_package)

ITK ships its own copy of HDF5 in Modules/ThirdParty/HDF5/; Homebrew's VTK 9.5 transitively find_package(HDF5) and trips over the partial target overlap (only some of the expected targets already exist when VTK's call sees them). Likely fixes:

• ITK_USE_SYSTEM_HDF5=ON + brew install hdf5 so both ITK and VTK consume the same Homebrew HDF5 — avoids the in-tree HDF5 target collision entirely.
• Or: order the find_package calls so VTK's HDF5 imports happen first, then ITK's bundled HDF5 is built without exporting the colliding targets.
• Or: investigate VTK 9.x's vtk-config.cmake to see whether the HDF5 dependency can be made optional / skipped when the consumer (ITK) doesn't ask for the VTK modules that need it.

Failure 2 — Qt5 not installed on Ubuntu 24.04 ARM runner

CMake Error at /usr/lib/aarch64-linux-gnu/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:115 (find_package):
  Could not find a package configuration file provided by "Qt5" (requested version 5.15)
Call Stack (most recent call first):
  /usr/lib/aarch64-linux-gnu/cmake/vtk-9.1/vtk-config.cmake:150 (include)
  Modules/Bridge/VtkGlue/itk-module-init.cmake:17 (find_package)

Ubuntu's libvtk9-dev was built with Qt5 wrappers; its config cascades into find_package(Qt5), which the runner doesn't have. Fixes:

• Add qtbase5-dev (and probably qttools5-dev, libqt5opengl5-dev) to the apt install list. Increases CI install time but is straightforward.
• Or: ask VTK for components only — find_package(VTK 9.1 NO_MODULE REQUIRED COMPONENTS IOImage ImagingSources ...) — so VTK's cascaded find_package calls only fire for components ITK actually needs. Need to verify VTK 9.1+ honours the COMPONENTS filter on transitive deps; some versions still execute the full graph.

Concrete plan

1. Reproduce locally on a clean macos-15 + Homebrew install with Module_ITKVtkGlue=ON to confirm fix A1 (ITK_USE_SYSTEM_HDF5=ON + brew install hdf5) closes the HDF5 issue without breaking the in-tree HDF5 builds.
2. Reproduce locally on a clean ubuntu-24.04-arm + apt-only install to confirm fix A2 (apt install qtbase5-dev qttools5-dev libqt5opengl5-dev) and pin the smallest workable Qt5 package set.
3. Re-add the vtk-glue: true matrix entries to .github/workflows/arm.yml with the install-step changes from (1) and (2).
4. Optionally: add the same coverage on the ITK.Pixi workflow once the pixi recipe gains a VTK dependency (separate concern).

Why this is separate from #6144

#6144's actual code change (drop the vtk_module_config shim, raise the floor to 9.1) is mechanical and merge-ready. The issues above are pre-existing surface problems that any find_package(VTK) would hit — the floor bump didn't introduce them. Bundling these together would block the floor-bump on a substantively larger engineering effort.