ci: build the Windows CUDA path (nvcc + MSVC host) — the one toolchain no job covers

engine-cuda-syntax compiles backend_cuda.cu with nvcc's GCC host on Linux, and
check.yml's windows job is MinGW/UCRT64 CPU-only by design (#140). Neither
exercises nvcc's MSVC host — the only host compiler nvcc accepts on Windows — so
`make cuda-dll` and `make glm CUDA_DLL=1` are currently built by nothing.

The gap has already cost real bugs, all compile-time, all catchable without a GPU:

  - #158: MSVC rejects the GCC-style -Xcompiler=-Wall,-Wextra ("D8021 invalid
    numeric argument '/Wextra'"), CUDA_HOME/NVCC defaults were unresolvable, and
    the kernel test used POSIX setenv. `make cuda-dll` was unbuildable as shipped.
  - #314: CUDA_HOME containing spaces — the CUDA installer's default layout. This
    job installs to exactly that path, so it reproduces the condition by default.

Two Windows-specific facts the job encodes, both verified by making it fail first:

  - sub-packages needs "cudart", not just "nvcc": cuda-dll *links* the runtime, and
    on Windows the headers/import lib are a separate installer component. With
    '["nvcc"]' alone it dies at `#include <cuda_runtime.h>` — the Linux syntax job
    never notices because it only compiles.
  - runs-on is pinned to windows-2022: windows-latest now ships Visual Studio 18
    (MSVC 14.5x) and CUDA's crt/host_config.h hard-errors on any host newer than
    VS 2022. That is a real constraint on every Windows CUDA user today, so the pin
    tracks what the toolkit supports rather than papering over it with
    -allow-unsupported-compiler.

Build-only on purpose: hosted runners have no NVIDIA device, so this proves the
Windows+MSVC CUDA build stays buildable, not that the kernels or the DLL loader
behave on real silicon — that still needs hardware (#157). A check that overclaims
buys the false confidence the engine-cuda-syntax comment already warns about.

Verified green on a fork before proposing:
https://github.com/lEWFkRAD/colibri/actions/runs/29524302993

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.github/workflows/ci.yml

@@ -41,6 +41,78 @@ jobs:
             -Xcompiler=-Wall,-Wextra
           echo "CUDA syntax check passed"
 
+  windows-cuda-build:
+    # The Windows CUDA path has no coverage anywhere: `engine-cuda-syntax` above
+    # compiles with nvcc's *GCC* host on Linux, and check.yml's windows job is
+    # MinGW/UCRT64 CPU-only by design (#140). But nvcc on Windows requires MSVC
+    # as its host compiler — it does not accept MinGW — so `make cuda-dll` runs a
+    # toolchain nothing else in CI touches. That gap is not theoretical: every
+    # bug in #158 was a *build* failure on this path (MSVC rejects the GCC-style
+    # -Xcompiler=-Wall,-Wextra with "D8021 invalid numeric argument '/Wextra'",
+    # unresolvable CUDA_HOME/NVCC defaults, POSIX setenv in the kernel test), and
+    # #314 was CUDA_HOME with spaces — the layout the CUDA installer ships by
+    # default. Both classes are compile-time and need no GPU to catch.
+    #
+    # Build-only ON PURPOSE: GitHub's hosted runners have no NVIDIA device, so
+    # this job proves the Windows+MSVC CUDA build stays buildable, NOT that the
+    # kernels or the DLL loader behave on real silicon. That still needs hardware
+    # (see #157). Claiming otherwise would be the false confidence the
+    # engine-cuda-syntax comment above already warns about.
+    name: CUDA build (Windows, MSVC host)
+    # windows-2022, NOT windows-latest: the latest image now ships Visual Studio
+    # 18 (MSVC 14.5x), and CUDA's crt/host_config.h hard-errors on any host newer
+    # than VS 2022 ("Only the versions between 2017 and 2022 (inclusive) are
+    # supported"). That is a real constraint for every CUDA user on Windows, not
+    # a CI quirk — pinning tracks what the toolkit actually supports. Revisit when
+    # a CUDA release accepts VS 18; -allow-unsupported-compiler would only mask it.
+    runs-on: windows-2022
+    steps:
+      - uses: actions/checkout@v4
+      - name: MSVC environment (puts cl.exe on PATH for nvcc -ccbin)
+        uses: ilammy/msvc-dev-cmd@v1
+      - name: Install CUDA toolkit (compiler only)
+        uses: Jimver/cuda-toolkit@v0.2.19
+        with:
+          # Same pin as engine-cuda-syntax: v0.2.19's version table stops at
+          # 12.6.2. This installs to the default "C:\Program Files\NVIDIA GPU
+          # Computing Toolkit\..." path, so CUDA_HOME is space-bearing here —
+          # which is exactly the #314 regression this job would have caught.
+          cuda: '12.6.2'
+          method: network
+          # cudart as well as nvcc: unlike the Linux job (which only needs to
+          # *compile* backend_cuda.cu), cuda-dll links it, and on Windows the
+          # runtime headers/import lib ship as a separate installer component —
+          # with '["nvcc"]' alone this fails at `#include <cuda_runtime.h>`.
+          sub-packages: '["nvcc", "cudart"]'
+      - uses: msys2/setup-msys2@v2
+        with:
+          msystem: UCRT64
+          update: false
+          # inherit: cl.exe (msvc-dev-cmd) and nvcc (cuda-toolkit) are added to
+          # the *Windows* PATH by the steps above; without inheriting it the
+          # recipe's `command -v` guards fail inside the MSYS2 shell.
+          path-type: inherit
+          install: >-
+            make
+            mingw-w64-ucrt-x86_64-gcc
+      - name: make cuda-dll (nvcc + MSVC host)
+        shell: msys2 {0}
+        run: |
+          cd c
+          # CUDA_ARCH is pinned: the default is `native`, which asks the driver
+          # what card is present — there is none here, so it must be explicit.
+          # sm_80 matches engine-cuda-syntax and is supported by the 12.6 pin.
+          make cuda-dll CUDA_ARCH=sm_80
+          test -f coli_cuda.dll || { echo "cuda-dll reported success but produced no DLL" >&2; exit 1; }
+          echo "coli_cuda.dll built (MSVC host)"
+      - name: make glm CUDA_DLL=1 (host links backend_loader, not cudart)
+        shell: msys2 {0}
+        run: |
+          cd c
+          make glm CUDA_DLL=1
+          test -f glm.exe || { echo "glm CUDA_DLL=1 reported success but produced no exe" >&2; exit 1; }
+          echo "glm.exe built against the DLL loader"
+
   web:
     name: Web UI
     runs-on: ubuntu-latest