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

[lEWFkRAD]

Follow-up to #157 — closing the gap rather than just reporting it.

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 built by nothing in CI today.

That gap has already cost real bugs, and every one was compile-time, catchable with no GPU present:

• cuda-dll: make the Windows CUDA build work as shipped — MSVC host flags, CUDA_PATH defaults, POSIX shim in kernel test (#157, first hardware validation of #131's loader) #158 — MSVC rejects the GCC-style -Xcompiler=-Wall,-Wextra (D8021 invalid numeric argument '/Wextra'), CUDA_HOME/NVCC defaults were unresolvable, kernel test used POSIX setenv. make cuda-dll was unbuildable as shipped.
• Add build-config stamp: flag changes (e.g. CUDA_DLL=1) force a relink instead of a silent stale binary #314 — CUDA_HOME containing spaces, i.e. the CUDA installer's default path. This job installs to exactly that layout, so it reproduces that condition by default rather than by luck.

Two Windows facts the job encodes — both found by making it fail first, not by reading docs:

1. sub-packages needs "cudart", not just "nvcc". cuda-dll links the runtime, and on Windows the headers/import lib ship as a separate installer component. With '["nvcc"]' alone it dies at #include <cuda_runtime.h>. The Linux syntax job never notices because it only compiles.
2. runs-on: 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's a live constraint on every Windows CUDA user right now, so the pin tracks what the toolkit actually supports. -allow-unsupported-compiler would only mask it.

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 (the sm_120 matrix in #157). I kept the scope explicit in the comments because a check that overclaims buys exactly the false confidence the engine-cuda-syntax comment already warns about.

It goes in ci.yml rather than check.yml deliberately — check.yml promises "no model downloads, no CUDA, no external deps — by design (#140)", and this needs an external toolkit action. Not going to break that contract.

Verified green on my fork before opening this, so it isn't landing in your queue untested: https://github.com/lEWFkRAD/colibri/actions/runs/29524302993

Creating library coli_cuda.lib and object coli_cuda.exp
coli_cuda.dll built (MSVC host)
glm.exe built against the DLL loader

Adds ~2 min to CI (the toolkit install dominates). Happy to gate it to paths (c/backend_cuda.*, c/backend_loader.c, c/Makefile) if you'd rather it not run on every PR — say which and I'll adjust.