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

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.