coverage: repair the Windows coverage wheels (#2508)

Windows coverage has not collected a test since 2026-03-17.  The job builds
its wheels with a plain `pip wheel`, which never reads [tool.cibuildwheel],
so the delvewheel repair every other Windows build performs never ran here.
Those wheels import a bare "MSVCP140.dll" and resolve it against whatever the
test machine has in System32, which on the coverage runner is 14.00.24215.1,
built in 2015.

_resource_handles.pyd is compiled by MSVC 14.44 and imports exactly _Mtx_lock
and _Mtx_unlock from that DLL -- never _Mtx_init_in_situ, because std::mutex
has had a constexpr constructor since VS 2022 17.10.  The 2015 runtime still
expects that initialisation and dereferences a null handle on the first lock,
which _stream.pyx takes while cuda.core is still importing.  It is the only
extension module in either package that locks a mutex, which is why
cuda.bindings and cuda.pathfinder have always passed on the same machine.

Repairing the wheels vendors msvcp140 14.44 into cuda_core.libs and rewrites
the import tables to match, so the process no longer depends on what the test
machine carries.  Verified on the coverage runner: 18 failed, 2929 passed,
918 skipped in 346s, against three to seven seconds of dying beforehand, and
the first Windows coverage data since March.

The same commit pins cuda-bindings to the wheel built one step earlier.
PIP_PRE is set so pip will consider that wheel at all -- it carries a .devN
version -- but it also admits PyPI's pre-releases, and cuda-bindings 13.4.0b1,
published 2026-07-29, outranks the local build.  Its cydriver.pxd comes from
CTK 13.4 headers where CUmemLocation has a `localized` field, while cuda.core
compiles against the 13.3.0 mini-CTK where it does not, so the build has been
failing on `error C2039` ever since.

Signed-off-by: Rui Luo <ruluo@nvidia.com>

Author: rluo8

.github/workflows/coverage.yml

@@ -235,13 +235,34 @@ jobs:
           cd cuda_bindings
           ../.venv/Scripts/pip wheel -v --no-deps . -w ../wheels/
 
+      # Pin cuda-bindings to the wheel built above; PIP_PRE, which is what makes
+      # that .devN wheel visible, would otherwise let a PyPI pre-release win.
       - name: Build cuda.core wheel
         run: |
           export PIP_FIND_LINKS="$(pwd)/wheels"
           export PIP_PRE=1
+          bindings_whl="$(ls ./wheels/cuda_bindings-*.whl | head -1)"
+          bindings_ver="$(basename "$bindings_whl" | cut -d- -f2)"
+          echo "cuda-bindings==${bindings_ver%%+*}" > "$GITHUB_WORKSPACE/constraints.txt"
+          cat "$GITHUB_WORKSPACE/constraints.txt"
+          export PIP_CONSTRAINT="$GITHUB_WORKSPACE/constraints.txt"
           cd cuda_core
           ../.venv/Scripts/pip wheel -v --no-deps . -w ../wheels/
 
+      # Vendor the DLLs these wheels were built against, the way cibuildwheel
+      # does for every other Windows build.  --namespace-pkg is needed because
+      # `cuda` is a namespace package.
+      - name: Repair the Windows wheels
+        run: |
+          .venv/Scripts/pip install delvewheel
+          mkdir -p wheels-repaired
+          for whl in ./wheels/cuda_bindings-*.whl ./wheels/cuda_core-*.whl; do
+            .venv/Scripts/delvewheel repair --namespace-pkg cuda \
+              --exclude "torch_cpu.dll;torch_python.dll" \
+              -w ./wheels-repaired "$whl"
+          done
+          mv -f ./wheels-repaired/*.whl ./wheels/
+
       - name: List wheel artifacts
         run: |
           echo "=== Windows wheel artifacts ==="