Stable ABI isn't stable when PyTorch changes the default CUDA version

### 🐛 Describe the bug

I work on xFormers and last year we made xFormers switch to the PyTorch stable API/ABI, so that our pre-built wheels would be forward-compatible with later PyTorch releases. This worked well, but this contract got "broken" when PyTorch switched its default CUDA version from 12.x to 13.x for the wheels pushed to pypi.org.

Concretely, this means that xFormers cannot push a single wheel to PyPI that will work across all PyTorch versions 2.10+ (which is what we're aiming for) because if we push a CUDA 12.x wheel we'll become incompatible with PT 2.12+ and if we push a CUDA 13.x wheel we become incompatible with PT 2.10-11.

To be clear, any installation happening from PyTorch's own indices (`https://download.pytorch.org/whl/cuXXY`) still works fine.

Is there a plan to make this work?

We could consider statically linking to the CUDA runtime within xFormers, but that seems a rather extreme solution.

### Versions

N/A

cc @malfet @atalman @tinglvv @nWEIdia @janeyx99 @ptrblck @msaroufim @eqy

No files, tests, or entry points are named. Start by reviewing the stable API/ABI contract and the PyPI wheel CUDA-version behavior described in the report; done would require an agreed approach that lets xFormers publish a compatible wheel across the stated PyTorch 2.10+ versions.

Written by the indexing model from the issue text.