fix(build): give nvcc the build's own MSVC as host compiler on Windows

[lusoris]

Summary

The required Windows MSVC+CUDA job failed on master because nvcc compiled the host side of the CUDA kernels with a different, older MSVC toolset than the rest of the build. On master 4bbbc1faa (run 37475182695, job 112308637968) Build libvmaf (CUDA) stopped at ciede_device.h(161): error: name followed by "::" must be a class or namespace name on every std::numbers::pi, after The contents of <numbers> are available only with C++20 or later., although nvcc ran with --std c++20. nvcc now uses the build's own cl.exe.

Evidence from that job's log:

• Meson's C and C++ compiler: cl (msvc 19.51.36260), the developer environment's toolset (VCToolsInstallDir ...\MSVC\14.51.36231\).
• nvcc's host compiler: Found MSVC cl.exe at: ...\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.exe and MSVC include: .../14.29.30133/include: the first cl.exe of Get-ChildItem -Recurse ... | Select-Object -First 1, the v142 toolset Visual Studio 2026 carries beside its own.
• That library does not expose <numbers> in nvcc's host passes; std::numbers::pi entered ciede_device.h with refactor(cuda): bring the CUDA kernels and their headers to the lint and HISS standard (ADR-1142) #2109. Every .cu host half was also compiled against another STL than the objects it links with.

Fix in the Windows block of core/src/meson.build (ported from the unmerged Netflix PR #1472, ADR-0150; upstream master has no such block): nvcc's -ccbin is the build's cl.exe when cxx is MSVC; otherwise the newest toolset under the latest vswhere install, sorted by [version]; otherwise cl on PATH. MSVC header discovery follows the chosen compiler as before.

Type

• fix — bug fix

Checklist

• Commits follow Conventional Commits (the commit-msg hook enforces this).
• make format && make lint is green locally — the commit hooks pass (black, HISS audit, generated-docs freshness).
• Unit tests pass: python3 core/test/test_windows_cuda_compiler_discovery.py → 7 OK; meson setup of a Linux CUDA build configures and runs the test through run_meson_test.py (1 OK).
• If I touched any SIMD/GPU code path, I ran /cross-backend-diff and the worst ULP is ≤ 2. — not applicable: build configuration only; no kernel or flag changes, Linux builds take the same path as before.
• If I touched a feature extractor with SIMD/GPU twins, I either updated every twin or listed the gap under "Known follow-ups" below. — not applicable.
• If I added a new .c / .cpp / .cu / .h / .hpp, it has the appropriate license header (see CONTRIBUTING.md). — not applicable: no native file.
• If this is a breaking change, the commit message uses ! or BREAKING CHANGE: and the migration path is documented below. — not a breaking change.
• If this PR adds an ADR, the ADR row lives in docs/adr/_index_fragments/<NNNN-slug>.md — not applicable: bug fix under ADR-0150.

Bug-status hygiene (ADR-0165)

• docs/state.md updated — opened and closed row T-WINDOWS-NVCC-CCBIN-OLDEST-TOOLSET-2026-10-06.

Netflix golden-data gate (ADR-0024)

• I did not modify any assertAlmostEqual(...) score in the Netflix golden Python tests.
• If I believe a golden value must change, I have explained why below — not applicable.

Deep-dive deliverables (ADR-0108)

• Research digest — no digest needed: trivial (the evidence is the job log quoted above).
• Decision matrix — alternatives in this body: replacing std::numbers::pi with a literal in ciede_device.h would hide the mixed toolsets and bring back the modernize-use-std-numbers finding refactor(cuda): bring the CUDA kernels and their headers to the lint and HISS standard (ADR-1142) #2109 removed; pinning a toolset version in the workflow would break with the next runner image. Using the build's own compiler is the invariant every other host object already follows.
• AGENTS.md invariant note — core/src/AGENTS.d/build-and-compiler.md "Windows CUDA compiler discovery" (index regenerated).
• Reproducer / smoke-test command — below.
• CHANGELOG fragment — changelog.d/fixed/windows-nvcc-ccbin-build-msvc.md.
• Rebase note — docs/rebase-notes.md "nvcc on Windows uses the build's MSVC".

User documentation: docs/getting-started/building-on-windows.md "Native MSVC and CUDA" lists the order.

Reproducer

python3 core/test/test_windows_cuda_compiler_discovery.py -v
# hosted: Builds workflow, job "Windows MSVC+CUDA" ("nvcc host compiler: the build MSVC at ...")

Gates shown failing on planted defects

Planted defect	Case	Result
master's discovery block	test_build_msvc_is_the_nvcc_host_compiler	fails: the stub refuses the vswhere search the block still runs
master's discovery block	test_build_msvc_comes_from_the_cpp_compiler	fails: no cxx derivation
master's discovery block	test_search_takes_the_newest_toolset	fails: -Recurse -Filter cl.exe
none (controls)	the four existing cases	pass on master and here

Known follow-ups

• Hosted proof: Windows MSVC+CUDA on this branch (workflow dispatch if the PR run is plan-skipped).