PLT-1623 ci(maturin): publish python 3.14 wheels and fix release race

[uptickmetachu]

Motivation

vrp-cli is the hard blocker for the Workforce 3.13 -> 3.14 upgrade (PLT-1623). uv lock --python 3.14 fails because the index has no wheel with a matching tag:

Because vrp-cli==1.25.4 has no wheels with a matching Python version tag (e.g., `cp314`) and your project depends on vrp-cli==1.25.4, we can conclude that your project's requirements are unsatisfiable.

hint: Wheels are available for `vrp-cli` (v1.25.4) with the following Python ABI tags: `cp312`, `cp313`

Worth recording, because it is not obvious: Workforce resolves from the s3pypi index at pypi.deployments.onuptick.com, which publishes filenames and sha256 only and carries no data-requires-python. Selection is therefore purely on the wheel tag. The data-requires-python values written into the gh-pages index are on a separate path that nothing consumes.

While confirming that, I found the release itself is broken. The workflow triggered on both push and release, so publishing a release started two concurrent runs that both uploaded the same asset names to the same release. Both v1.25.4 runs failed on that race (Not Found - update-a-release-asset and Error creating policy). The pypi-publish job is separate and still succeeded, which is why 1.25.4 wheels exist on s3pypi while the GitHub upload failed and the gh-pages index has been stale at 1.25.3 ever since. That would have broken this release too.

Changes

Build 3.14 wheels — added a setup-python 3.14 step to the linux and macos jobs and extended both build args to -i 3.12 -i 3.13 -i 3.14. No pyo3 bump is needed: 0.25.1 already supports 3.14, and the manylinux2014 image already ships cp314.

Fix the release race — push is now limited to branches: ["**"] so a tag push no longer starts a duplicate run, both publish jobs are gated on the release event, and a concurrency group cancels superseded branch builds without ever cancelling a release.

Manual publishing — still available via workflow_dispatch, but only from a tag. action-gh-release falls back to github.ref, so a dispatch from master would otherwise create a release named master.

Version — bumped to 1.25.5.

The gh-pages index parser is unchanged. It reads cp314 and writes ==3.14, which is correct for per-interpreter wheels.

Test plan

Everything below was run locally, not assumed.

• Built with the exact workflow args on macOS. Produced vrp_cli-1.25.5-cp312, -cp313 and -cp314-cp314-macosx_11_0_arm64 wheels.
• Ran the linux path inside the real quay.io/pypa/manylinux2014_x86_64 container with the same args. maturin reported Found CPython 3.12, CPython 3.13, CPython 3.14 and compiled once per interpreter.
• Installed the cp314 wheel on Python 3.14.3 and called get_routing_locations. It returns correctly.
• Verified the call shape Workforce actually uses, solve_pragmatic(**kwargs). Keyword binding works and a bad payload raises OSError, which is what abas/utils/scheduling/vrp_cli/service.py wraps into VrpException.
• Confirmed python-version: "3.14" resolves on the pinned setup-python v4.9.1, whose manifest lists 3.14.4 through 3.14.7.
• Validated the workflow YAML and the four job conditions.

Pushing this branch runs the build jobs without publishing, so CI is the final check on the 3.14 build before the release is cut.

Follow-up

Workforce must move its pin from vrp-cli==1.25.4 to ==1.25.5 in pyproject.toml. That belongs on the Workforce side of PLT-1623.

This keeps the existing per-interpreter approach, so 3.15 will need the same two-line change again. A single abi3-py312 wheel would end that permanently, and I verified one runs on 3.12, 3.13 and 3.14 with the current pyo3. Deliberately out of scope here.