COMP: Pinned CastXML 0.6.5 cannot parse gcc-toolset-14 `<limits>` (`_Float32`/`F32`) — blocks all manylinux_2_28 wheel builds

The CastXML 0.6.5 binary used by the manylinux_2_28 wheel builds cannot parse GCC 14's ``, so **every** Linux Python wrapping job fails for remote modules — on `main`, not only on PRs. CastXML 0.7.0 (2026-02-25) postdates the pin and the equivalent gcc-13 defect was fixed upstream, so bumping the pinned CastXML is the likely fix.

Failure detail and error text

manylinux_2_28 dockcross containers now ship `gcc-toolset-14`. GCC 14's `` uses the `__glibcxx_float_n(32)` macro family, which expands to `F32` floating literal suffixes and `__builtin_huge_valf32`. CastXML 0.6.5's embedded Clang does not support these:

```
invalid suffix 'F32' on floating constant
typedef redefinition with different types ('float' vs 'struct __castxml_Float32_s')
```

Reported location: `/opt/rh/gcc-toolset-14/root/usr/include/c++/14/limits:1989`.

Scope of impact

- All 8 Linux Python wrapping jobs fail.
- Reproduced on module `main` branches — this is not introduced by any PR.
- Affects **any** ITK remote module that builds Python wheels on manylinux_2_28, i.e. the whole remote-module wheel fleet.
- First observed during CI triage of ITKMontage PR #242 (merged 2026-04-15).

Upstream status and suggested fixes, in order of preference

- CastXML releases since the 0.6.5 pin: v0.6.9, v0.6.10 (2024-11-27), v0.6.11 (2025-02-11), v0.6.12/v0.6.13 (2025-08-28), **v0.7.0 (2026-02-25)**.
- Upstream CastXML#251 "gcc-13.2.0 unknown type name `_Float32`" — CLOSED 2024-01-23. Same defect class, already fixed for gcc-13.

1. **Bump the pinned CastXML binary** in the wheel-build docker images to v0.7.0 (or ≥0.6.10) and re-run a Linux wrapping job. This is the expected fix and should be tried first.
2. If 0.7.0 still fails on gcc-14, file a fresh upstream issue at https://github.com/CastXML/CastXML with the `limits:1989` reproducer.
3. Stop-gap: pin the dockcross image tags back to a `gcc-toolset-13` revision.
4. Alternative: configure CastXML to use its own bundled Clang headers rather than the GCC toolset headers.

Start by locating the pinned CastXML binary in the wheel-build Docker image definitions and checking the current Linux wrapping configuration. Update the pin to a supported release, run a manylinux_2_28 Linux wrapping job, and consider the issue done when the affected Python wheel jobs pass with GCC 14.

Written by the indexing model from the issue text.