Windows + macOS wheel build for ITK 6.0b02 cannot wrap modules including C++17-only headers (CMAKE_CXX_STANDARD=14 baked into pre-built archives)

# Windows wheel build for ITK 6.0b02 cannot wrap modules that include C++17-only ITK headers

## Summary

The pre-built `ITKPythonBuilds-windows.zip` published with the [`v6.0b02`](https://github.com/InsightSoftwareConsortium/ITKPythonBuilds/releases/tag/v6.0b02) release ships a wrapping configuration that invokes `castxml` with `-std:c++14`. ITK 6.0b02 itself requires C++17 (see `CMakeLists.txt`, the explicit `FATAL_ERROR` for `CMAKE_CXX_STANDARD < 17`), and several public headers contain C++17-only syntax — most notably the class template argument deduction (CTAD) guide at `Modules/Core/Common/include/itkArray.h:217`:

```cpp
template
Array(TValue *, typename vnl_vector::size_type, bool) -> Array;
```

`castxml` invoked with `-std:c++14` rejects this with `error: a type specifier is required for all declarations`, breaking every remote-module Python wheel build on Windows whose `.cxx` wrapping inputs transitively `#include ` (which is essentially all of them).

## Affected platforms / versions

- Host: `windows-2022` GitHub Actions runner (and any equivalent MSVC environment)
- Pre-built archive: `ITKPythonBuilds-windows.zip` from `v6.0b02`
- ITK source: `v6.0b02`
- ITKPythonPackage: `v6.0b02` (and tested with `main` HEAD `2b655cb931`) — neither helps; this is a build-time-baked issue in the pre-built archive, not a wheel-build script issue.

Linux and macOS wheel builds for the same matrix are unaffected (their pre-built archives appear to use the project's `CMAKE_CXX_STANDARD` correctly).

## Repro

In any ITK remote module's wheel-build workflow that uses ITKPythonBuilds `v6.0b02`:

```yaml
env:
itk-wheel-tag: v6.0b02
itk-python-package-tag: v6.0b02 # or any newer commit on main

jobs:
build-windows-opencl-python-packages:
runs-on: windows-2022
strategy:
matrix:
python-version-minor: ["10", "11"]
steps:
- uses: actions/checkout@v5
- run: |
curl -L "https://github.com/InsightSoftwareConsortium/ITKPythonBuilds/releases/download/${{ env.itk-wheel-tag }}/ITKPythonBuilds-windows.zip" -o ITKPythonBuilds-windows.zip
7z x ITKPythonBuilds-windows.zip -o/c/P -aoa -r
# ... build wheels via IPP/scripts/windows_build_module_wheels.py ...
```

This produces:

```
[NN/89] castxml.exe ... --castxml-cc-msvc ( ... -std:c++14 ) ... itkVkComplexToComplex1DFFTImageFilter.cxx
In file included from C:/P/IPP/ITK-win_311-x64/Wrapping/castxml_inputs/itkVkComplexToComplex1DFFTImageFilter.cxx:6:
C:/P/IPP/ITK-source/ITK/Modules/Core/Common/include/itkArray.h:217:1: error: a type specifier is required for all declarations
3 errors generated.
FAILED: [code=1] C:/P/IPP/ITK-win_311-x64/Wrapping/castxml_inputs/itkVkComplexToComplex1DFFTImageFilter.xml
```

Concrete log: (job `build-windows-opencl-python-packages (11)` from `ITKVkFFTBackend#74`).

## Root cause

Castxml is invoked by the `add_custom_command` written into the pre-built ITK install tree (`C:/P/IPP/ITK-win_311-x64/Wrapping/castxml_inputs/*.castxml.inc`). The compiler-driver flag list in those generated `.inc` files contains `-std:c++14`. The flag was injected at the time ITKPythonBuilds CI built `ITK-win_311-x64` — i.e. that build was configured with `CMAKE_CXX_STANDARD=14`, even though ITK 6.0b02's top-level `CMakeLists.txt` requires `>= 17`.

The most likely culprit is the CI configuration that produces `ITKPythonBuilds-windows.zip` — it probably still passes (or defaults to) `CMAKE_CXX_STANDARD=14`. Linux and macOS variants of the archive either pass `-std=c++17` or pick it up implicitly from a newer compiler default.

## Proposed fix

Update whichever CI script builds the Windows half of `ITKPythonBuilds` so that `CMAKE_CXX_STANDARD=17` (or higher) is passed when configuring `ITK-win_*-x64`. The propagated value will land in the generated `castxml_inputs/*.castxml.inc` and unblock all downstream remote-module wheel builds on Windows.

Affected file is likely one of:
- `InsightSoftwareConsortium/ITKPythonBuilds/.github/workflows/build-windows-package.yml` (or whatever Windows-build workflow drives the release tarball)
- The equivalent script in `InsightSoftwareConsortium/ITKPythonPackage/scripts/internal/` if the build is delegated there

Re-tag and release as `v6.0b03` (or a `v6.0b02.postN`) once the rebuilt zip is produced.

## Workaround for affected modules

Until a fix is released, downstream remote modules can disable the Windows Python wheel job, e.g.:

```yaml
build-windows-opencl-python-packages:
if: false # blocked on ITKPythonBuilds windows-zip castxml -std:c++17
runs-on: windows-2022
# ...
```

Linux and macOS wheel jobs remain functional after the Python-3.10+ build-script fixes that landed on `ITKPythonPackage:main` (PR #304 + `a2d2a5fa` "Bootstrap pip via ensurepip on Windows wheel build to fix Python 3.10+") — so module wheels can still ship for those platforms.

## Additional context

- ITK source confirmation that C++17 is mandatory: — `FATAL_ERROR` when `CMAKE_CXX_STANDARD < 17`.
- The C++17 CTAD guide that breaks parsing: .
- Two C++17 constructs in ITK 6 that castxml-with-c++14 will reject — `itkArray.h:217` is the first hit; expect to surface more once that one is fixed.
- ITKPythonBuilds `main` branch is dormant (HEAD `bb6c9bab` from 2017-06-14, "Add links in README") — the release-tag workflow is the only effective channel here.