Add Python 3.14 to the CI matrix

[gagelarsen]

Second repo in the 3.14 rollout, following xmscore. Same shape as xmscore#131, which is merged and released as 7.0.13.

The change

build.toml only — everything else in the diff is regenerated by xmsconan_ci at 2.21.0:

xms_dependencies = [{ name = "xmscore", version = "7.0.13" }]   # was 7.0.12

[ci]
python_versions       = ["3.10", "3.13", "3.14"]   # Windows
mac_python_versions   = ["3.13", "3.14"]
linux_python_versions = ["3.13", "3.14"]

Why the xmscore bump is required, not incidental

Conan propagates python_version to xms_dependencies, and the generated CI runs build.py without --build-missing. So a 3.14 pybind leg here needs a prebuilt xmscore binary at that ABI or Conan fails resolution outright. 7.0.12 predates 3.14 support and has none.

xmscore 7.0.13 now carries them — verified on the remote rather than assumed:

$ conan list "xmscore/7.0.13:*" -r aquaveo
msvc 194        pybind=True  python_version=3.10 / 3.13 / 3.14
gcc 13          pybind=True  python_version=3.13 / 3.14
apple-clang 17  pybind=True  python_version=3.13 / 3.14

Three lists, not one

Windows carries 3.10 for the desktop products' wheel and nothing else needs it. Every Linux entry needs a published conan-gcc13-py<version> container, and those exist for 3.13 and 3.14 only — there is no py3.10/3.11/3.12 image on either registry. So Linux can't simply track python_versions.

What to expect on merge

• Release asset and wheel-artifact names change on macOS and Linux, gaining -py<version>: linux-GCC13-Release-py3.13.tar.gz rather than linux-GCC13-Release.tar.gz. Those platforms produce two ABIs each now and the old names would have one leg overwrite the other. Windows already worked this way. Anything fetching these by exact name needs updating.
• The linux job's status-check name gains the ABI. master has no required_status_checks configured, so nothing is blocked by the rename — I checked before pushing.
• A tagged release will publish 7 wheels instead of 4: 3.10/3.13/3.14 on Windows, 3.13/3.14 on macOS and Linux. Distinct cp3XY tags, so they coexist. Wheel upload stays gated on refs/tags/ plus build_type == 'Release', so this PR itself publishes nothing.

CI time and Conan storage roughly double, as they did for xmscore.

No coverage pin needed

xmsgrid doesn't set [ci].coverage, so there's no Coverage.yaml whose Python version could drift. xmscore needed [coverage].python_version = "3.13" because coverage there follows the highest Linux entry and would otherwise have moved to 3.14 as a side effect.

Risk

Low, relative to xmscore. That PR was the first compile of anything in the suite against the 3.14 C API, and it passed on MSVC, Clang and GCC — so the pybind layer is proven. xmsgrid has its own bindings, so this run is still the first look at its glue against 3.14, but the shared foundation is known good.

Post-merge plan, once green: tag 9.1.1 (patch — the change is CI plus a dependency bump, no library source change), then the manual VS2019 pass and its cp310 wheel to aquaveo/stable.

[gagelarsen]

CI green — all 15 legs, including every 3.14 leg on all three platforms:

success  Clang-Latest (Release, 3.14, Macos)        success  GCC-13 (Release, 3.14, Linux)
success  Clang-Latest (Debug, 3.14, Macos)          success  GCC-13 (Debug, 3.14, Linux)
success  Visual Studio 17 (Release, 3.14, Windows)  success  Visual Studio 17 (Debug, 3.14, Windows)

That covers the one thing this PR could still teach us: xmsgrid's own pybind bindings compile and pass their tests against the Python 3.14 C API on MSVC, Clang and GCC. It also confirms the dependency bump works end to end — the 3.14 legs resolved xmscore/7.0.13 at python_version=3.14 from the remote, which is exactly what would have failed against 7.0.12.

Ready for review. The warning annotations on the run are the pre-existing Node 20 deprecation ones, unrelated to this change and tracked in Aquaveo/xmsconan#102.

[gagelarsen]

Correction to my comment above: when I said "CI green" I had only looked at the pull_request run. The push run on the same commit failed, and I should have checked both before reporting. It is green now, after a re-run, but the cause is worth recording.

What failed

One job — Visual Studio 17 (Release, 3.13, Windows) — with four configurations dying on:

ERROR: Permission denied for user: 'None': 403: Forbidden. [Remote: conancenter]

Not a 3.14 problem: the four failing configurations were all pybind=False, so ABI-independent, and the leg was 3.13. No compile error and no test failure — I initially mis-grepped 100% tests passed, 0 tests failed out of 1 as a failure; there wasn't one.

Cause

The generated workflow passes --remove-conancenter on mac only. Linux and Windows leave conancenter in the remote list, so Conan consults it during resolution and a 403 from it fails the build — on a registry that supplies none of our dependencies. Two runs of 15 jobs each hitting it at the same moment is a plausible throttle.

Re-run: all 15 jobs green, no changes. Filed the underlying asymmetry as Aquaveo/xmsconan#104 — adding --remove-conancenter to the linux and windows steps is a three-line template fix, and mac already proves nothing in the graph needs that remote.

Worth noting the exposure grew with this change: the 3.14 fan-out roughly doubled the job count per repo, so it roughly doubled the number of conancenter calls per run. This surfacing on the first repo after the fan-out is probably not a coincidence.

Still ready for review — the diff is unchanged.