Regenerate CI with xmsconan 2.23.0

[gagelarsen]

Unblocks master, red since 2026-08-21 on all seven Debug legs. CI-only — no source, build.toml or version change.

Why master is red

xmsconan 2.22.0 made --wheel-dir a request build.py must satisfy, exiting 1 when no complete set of wheels comes out. The workflow passed the flag on every build type, and [matrix].pybind_build_types defaults to Release only — so a Debug leg has no pybind configuration to extract a wheel from:

 >> All configurations built successfully.
 >> No pybind package found to extract.
error: --wheel-dir wheelhouse was given but no complete set of wheels was extracted; see the message above.

Nothing to do with the 3.14 change in 6cf0b20 — that same commit passed 15/15 on xmsconan 2.21.0 hours before 2.22.2 published.

Why it needs a commit here

build.py is regenerated on every CI run, so the floating xmsconan>=… --upgrade pin delivered the breaking change automatically. The workflow YAML is committed, so the fix only arrives by regenerating. xmsconan 2.23.0 gates the flag on matrix.build_type == 'Release' — how repair, artifact upload and deploy in this same workflow were already gated (Aquaveo/xmsconan#110, Aquaveo/xmsconan#111).

Also in this regeneration

All from xmsconan 2.23.0, none of it opt-in:

• Third-party actions pinned to commit SHAs, tag kept in a trailing comment. A tag is a movable ref in someone else's repository, and these steps run with this workflow's secrets in their environment.
• actions/setup-python v2 → v5 on the flake job.
• flake8-tidy-imports added. It registers banned-modules, which the generated .flake8 sets. flake8 ignores config options no installed plugin claims, so the osgeo ban was silently enforcing nothing while the job reported the same green as a run that had checked it.
• xmsconan floor 2.21.0 → 2.23.0.

After this merges

master should return to 15/15, and 9.1.1 gets tagged from it.