Publish CUDA wheels for Python 3.14 (pytorch#22010)

## The problem

The CUDA wheel rows build Python 3.10 through 3.13. The CPU rows already
build 3.14. So a user on Python 3.14 can install a CPU wheel and has
nothing to install for a GPU.

## Why 3.14 was excluded, and why that reason is gone

The exclusion was correct when it was written, and it was not about CUDA
at all.

Both the CPU and the CUDA rows run `install_requirements.sh --example`
from the shared pre-build script
(`.ci/scripts/wheel/pre_build_script.sh:143`). On 3.14 that install
failed:

```
Collecting pyarrow<21.0.0 (from torchtune ...-r requirements-examples.txt (line 6))
  Downloading pyarrow-20.0.0.tar.gz
ERROR: Failed building wheel for pyarrow
```

`torchtune` caps `pyarrow` below 21, no `pyarrow` in that range ships a
Python 3.14 wheel, so pip fell back to the source archive and the Arrow
C++ build failed. A GPU row added at that point would have inherited a
build that was already known to fail.

That failure is now fixed. `requirements-examples.txt:9` carries an
environment marker:

```
torchtune @ git+https://github.com/pytorch/torchtune.git@3c1872ac ; python_version < "3.14"
```

With that in place the CPU 3.14 rows build and pass their smoke test, so
the reason for holding the GPU rows back no longer applies.

## Dependencies

Every exact pin a CUDA row installs publishes a Python 3.14 wheel for
the CUDA versions this matrix builds, on both x86_64 and aarch64.
`torchao` ships as `cp310-abi3`, which a 3.14 interpreter accepts. The
two CUDA runtime packages are `py3-none` universal.

The free-threaded exclusions are unchanged. Their CUDA dependencies
still do not publish, so `3.13t`, `3.14t`, `3.15` and `3.15t` stay
disabled.

## Why this touches three files

The python list is stated in three places that have to agree:

```
.github/scripts/filter_cuda_matrix.py        SUPPORTED_PYTHON_VERSIONS
.github/workflows/build-wheels-cuda-linux.yml          python-versions
.github/workflows/build-wheels-cuda-aarch64-linux.yml  python-versions
```

Updating only the script leaves the upstream generator offering four
pythons while the script expects five. The release guard compares those
two numbers and reports a row-count mismatch, which is the behaviour the
comment at `filter_cuda_matrix.py:60-64` describes. All three are
updated together.

## Testing

Ran the real filter against a matrix covering 3.10 through 3.15
including the free-threaded builds, and confirmed it keeps exactly the
intended 15 rows:

```
3.10  cu126 cu130 cu132
3.11  cu126 cu130 cu132
3.12  cu126 cu130 cu132
3.13  cu126 cu130 cu132
3.14  cu126 cu130 cu132
```

No free-threaded row, no 3.15 row, and no unsupported CUDA version
survives the filter.

Also confirmed the failure mode described above. With the script updated
and a workflow left at four pythons, the filter yields 12 rows where the
script expects 15, which is exactly what the release guard compares.

## What is not verified

No Python 3.14 CUDA row has ever been built, because none could exist
before this change. What is established here is that the blocker is
removed and the inputs are present, not that the row is green. The
x86_64 CUDA smoke test runs a model on a real GPU, and no 3.14 wheel has
done that yet, so this needs a full matrix run before a release depends
on it.

Author: shoumikhin

.github/scripts/filter_cuda_matrix.py

@@ -32,13 +32,12 @@
 
 # Python versions that are deliberately NOT published, with the reason, so a row naming one
 # is rejected for a stated cause rather than for merely being absent from the supported list.
-# 3.14 is excluded because the current CPU wheel rows already fail on it for an unrelated
-# reason in the example requirements, so a GPU row would inherit a known-broken build. The
-# free-threaded builds are excluded because the CUDA dependencies are not published for them.
+# The free-threaded builds are excluded because the CUDA dependencies are not published for
+# them.
 #
 # This is documentation, not the gate. The gate is SUPPORTED_PYTHON_VERSIONS below: anything
 # not on that list is rejected whether or not it appears here.
-DISABLED_PYTHON_VERSIONS: List[str] = ["3.13t", "3.14", "3.14t", "3.15", "3.15t"]
+DISABLED_PYTHON_VERSIONS: List[str] = ["3.13t", "3.14t", "3.15", "3.15t"]
 
 # CUDA versions to publish.
 #
@@ -62,7 +61,7 @@
 # guard below unable to notice a python that disappeared from every supported train: with
 # nothing left to compare, a release quietly published nine wheels instead of twelve.
 # Keep in step with the python-versions list in the CUDA wheel workflows.
-SUPPORTED_PYTHON_VERSIONS: List[str] = ["3.10", "3.11", "3.12", "3.13"]
+SUPPORTED_PYTHON_VERSIONS: List[str] = ["3.10", "3.11", "3.12", "3.13", "3.14"]
 
 # The single row built for a pull request. A full matrix on every push would cost hours for
 # little signal, and cu130 is the version with a machine on hand that can run a model on it.

.github/workflows/build-wheels-cuda-aarch64-linux.yml

@@ -48,7 +48,7 @@ jobs:
       with-cuda: enable
       with-cpu: disable
       with-rocm: disable
-      python-versions: '["3.10", "3.11", "3.12", "3.13"]'
+      python-versions: '["3.10", "3.11", "3.12", "3.13", "3.14"]'
 
   # The generator emits every CUDA version it knows about. Publishing all of them would ship
   # wheels for combinations nothing can verify, so this keeps only the rows a device exists for

.github/workflows/build-wheels-cuda-linux.yml

@@ -48,7 +48,7 @@ jobs:
       with-cuda: enable
       with-cpu: disable
       with-rocm: disable
-      python-versions: '["3.10", "3.11", "3.12", "3.13"]'
+      python-versions: '["3.10", "3.11", "3.12", "3.13", "3.14"]'
 
   # The generator emits every CUDA version it knows about. Publishing all of them would ship
   # wheels for combinations nothing can verify, so this keeps only the rows with a GPU to run