[M1-DET-01] Fix Windows CI: quote the trait_compile fixture compiler invocation

[offdev]

What fails

The Windows x64 (MSVC 2022) job on master (run 34984988547, commit 07fc79e) fails in the four G-R8 trait compile-check fixtures — trait_compile_ok, trait_compile_reject_double, trait_compile_reject_unmarked, trait_compile_reject_bad_mark — each reporting:

G-R8 compile check failed [exit code no such file or directory (expected 0 — the fixture must compile)]

with empty compiler output. no such file or directory is CMake's literal RESULT_VARIABLE for a failed process launch — the compiler never started.

Root cause (two independent defects, both Windows-only)

1. The compiler path is re-split on whitespace. expect-compile-result.cmake.in interpolates the compiler into an unquoted execute_process(COMMAND @CXX@ ...) line. configure_file substitutes plain text, and unquoted text in the generated script is re-split on whitespace by the CMake parser, so the MSVC compiler path

C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe

becomes the argument C:/Program — which does not exist. The Linux/macOS compilers (/usr/bin/g++, /usr/bin/clang++) contain no spaces, which is why only the Windows job fails.

2. cl has no MSVC environment. Once the path is quoted and cl actually launches, it runs outside the VS generator's toolchain setup (every other test in the job is a pre-built executable or an MSBuild invocation, which set up the toolchain themselves). The runner's plain shell has no INCLUDE/LIB/PATH, so cl dies with fatal error C1083: Cannot open include file: 'cstdint'.

Fix (per commit)

1. Quote the compiler invocation. laige_add_compile_check builds the invocation as a CMake list (one process argument per element) and serializes each element quoted into the generated script; the script runs execute_process(COMMAND ${_cmd}), whose list expansion passes each element as exactly one argument regardless of whitespace. Flag sets are unchanged (same tokens, same order, same semantics). This also future-proofs the fixtures against local Windows checkouts whose path contains spaces.
2. Give the fixtures the MSVC environment. The Windows Test (unit) step in both workflows now imports the VS development environment into the step before ctest: vswhere locates the installation, VsDevCmd.bat (the canonical vcvars, present in every VS 2017+ install under Common7\Tools; called by relative name from that directory, so no path quoting is involved) sets INCLUDE/LIB/PATH etc., and its set dump is imported variable by variable. ctest → cmake -P → cl inherit it. Everything else in the job is unchanged. (First attempt used LaunchVsDevEnv.ps1, which does not exist on this runner image — VsDevCmd.bat is the stable, version-proof equivalent.)
3. Same latent defect, one class below. expect-lint-result.cmake.in / expect-det-lint-result.cmake.in interpolate @PYTHON@ (the find_program result, a full interpreter path) unquoted into the generated execute_process. CI never hit it because the runner's python lives in C:/hostedtoolcache (no spaces); a local Windows checkout with python under C:/Program Files/Python3xx would fail identically. Quoted, aligning with the api/detcheck/compile-check scripts.

Verified

• cmake -P end-to-end simulation with a space-containing compiler path: every argument arrives intact (rc=0).
• Local g++ and clang++ trees: full ctest 55/55; ctest -R trait_compile 4/4 (also 4/4 in the ASan and TSan trees); lint/api/detcheck families 27/27 in the g++ tree.
• Windows proof: this PR's ci:windows job (label applied) — the earlier red run is exactly what exposed defect 2; the green target is the VsDevCmd.bat commit.