fix(ci): pin both cp314 and cp314t ABIs explicitly for Python 3.14

[antonwolfy]

Summary

A follow-up fix to #2340. That PR stopped the original 3.14 upload collision by pinning the free-threaded variant (*_cp314t), but left the GIL variant relying on a bare conda build --python 3.14. On master the collision has returned — this time both 3.14 jobs produce cp314t artifacts.

Failing run:
https://github.com/IntelPython/dpctl/actions/runs/30375407697/job/90332791079

Uploading file "dppy/dpctl/0.23.0dev0/dpctl-0.23.0.dev0+213.g5aa1f779ab-213-cp314-cp314t-manylinux_2_28_x86_64.whl"

— the job labeled upload_linux (3.14) (the GIL variant) uploads a cp314t (free-threaded) wheel.

Root cause

The assumption behind #2340 was that a bare conda build --python 3.14 resolves to the GIL interpreter (*_cp314), so only the free-threaded entry needed an explicit spec. That default is no longer reliable.

conda-forge has bumped the free-threaded python_abi to a higher build number than the GIL one (8_cp314t), and conda-build's solver — given an unconstrained --python 3.14 — picks the highest build number. It now resolves to cp314t.

The build logs confirm it. Job build_linux (3.14) ran conda build --python 3.14 (empty spec branch) but its host env resolved:

python:      3.14.6-hf9ea5aa_1_cp314t
python_abi:  3.14-8_cp314t

producing a cp314-cp314t wheel and a conda package depending on python_abi 3.14.* *_cp314t. So both 3.14 jobs became free-threaded, the GIL build vanished, and the two uploads collided on the identical cp314t wheel filename.

(Python 3.13 is unaffected: its highest python_abi build is still the GIL 8_cp313, so a bare --python 3.13 correctly resolves to cp313.)

Fix

Never rely on a bare --python 3.14. Removed 3.14 from every base python list and defined both ABIs as explicit, pinned matrix entries:

python: ['3.10', '3.11', '3.12', '3.13']
python_spec: ['']
include:
  - python: '3.14'
    python_spec: '3.14.* *_cp314'    # GIL
  - python: '3.14'
    python_spec: '3.14.* *_cp314t'   # free-threading

With both entries carrying a non-empty spec, the build/test/install steps take the explicit-ABI branch (conda build --python "$python_spec") instead of the bare---python fallback. The bare fallback now only serves 3.10–3.13, which have no free-threaded variant and thus no flip hazard. The artifact-naming and cache-key expressions already key off contains(python_spec, 'cp314t'), so they remain correct.

Note for future Python versions

This is the more robust pattern: whenever a Python version ships both GIL and free-threaded builds, pin both ABIs explicitly rather than trusting whichever python_abi build number the solver happens to prefer — that ordering can (and did) change under us.

[github-actions]

Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞

[coveralls]

coverage: 74.579%. remained the same — fix-ci-pin-both-314-abis into master