ci(windows): propagate cmake/ninja build failures out of the Build step

[Fedr]

Problem

On run 24691107383, msvc-2019 Release CMake job 72213000966, the `Build` step reported a green `success` despite ninja saying:

[775/895] Linking CXX shared library bin\MRViewer.dll
FAILED: [code=4294967295] bin/MRViewer.dll bin/MRViewer.lib
cpr.lib(util.cpp.obj) : error LNK2019: unresolved external symbol __std_find_trivial_1 ...
cpr.lib(session.cpp.obj) : error LNK2001: unresolved external symbol __std_find_trivial_1
cpr.lib(util.cpp.obj) : error LNK2019: unresolved external symbol __std_find_first_of_trivial_pos_1 ...
cpr.lib(threadpool.cpp.obj) : error LNK2019: unresolved external symbol _Cnd_timedwait_for_unchecked ...
bin\MRViewer.dll : fatal error LNK1120: 3 unresolved externals
...
ninja: build stopped: subcommand failed.

After that, the script ran `xcopy` and exited 0. GitHub Actions marked the step `success`. The next step, `Generate and build Python bindings`, then tried to link `mrcudapy.pyd` against `MRCuda.lib` — which was never produced because MRCuda's link target was downstream of the failed MRViewer target — and failed with a confusing

lld-link: error: could not open 'MRCuda.lib': No such file or directory

…67 seconds after the real failure the Build step should have reported. Debugging that error points at CUDA / MRCuda / mrbind, none of which is the actual problem.

Root cause

The `Build` step used an `if errorlevel 1 exit 1` check after each command inside a parenthesized IF block in a `shell: cmd` batch script:

if 1==1 (
    cmake --build source\TempOutput -j
    if errorlevel 1 exit 1
    ...
)

`if errorlevel 1` inside a parenthesized IF block in cmd.exe has well-known quirks where it can fail to catch exit codes from commands earlier in the same block (related to cmd.exe's parse-time expansion / single-pass parsing of parenthesized constructs). The check happened not to trigger for cmake/ninja's non-zero exit in this run; the script fell through to the next command.

The pattern had been in place for a while but was likely never exercised by a ninja-level build failure before this PR's unusual combination (#5932's overlay cascaded an ABI change through cpr → freetype → MRViewer, exposing a latent MSVC STL/cpr compatibility issue in the msvc-2019/vcpkg-2024.10.21 matrix entry, which triggered a link failure that the error-propagation pattern couldn't catch).

Fix

Replace each `if errorlevel 1 exit 1` with `|| exit /b 1` chained directly to the preceding command. `||` is evaluated at process-exit time rather than via cmd.exe's errorlevel-in-parens parsing, and is the documented idiom for robust error propagation in batch files.

-  cmake --build source\TempOutput -j
-  if errorlevel 1 exit 1
+  cmake --build source\TempOutput -j || exit /b 1

Applied to all six commands inside the CMake branch of the IF (VsDevCmd, cmake --version, cmake -B, cmake --build, mkdir, xcopy) and to the msbuild command in the ELSE branch.

Functional change

• When the build succeeds: no behavior change. `|| exit /b 1` evaluates to no-op when the left side returns 0.
• When any build command fails: the step now exits with code 1 at the point of failure, and GitHub Actions reports the step as `failure` with the log pointing at the real cause. Previously, most failures would still be caught (`if errorlevel 1` is not universally broken), but the subset that the parse-time-expansion quirks miss — like the one observed here — will now be caught reliably.

Not in this PR

• Other steps in the same workflow use the same `if errorlevel 1 exit 1` pattern inside `shell: cmd` blocks (`Build MRBind`, `Generate C bindings`, `Generate and build Python bindings`, `Install MSYS2 for MRBind`, etc.). They may have the same latent bug. Left alone here to keep the PR scoped to the one step with a concrete reproducer. A follow-up PR could audit all of them.
• The MSVC STL vs cpr incompatibility that caused the MRViewer link failure in the first place is a different issue; this PR doesn't address it, only the error-propagation problem it exposed. The underlying MRViewer link failure is a separate discussion (likely: bump msvc-2019's vcpkg-version off `2024.10.21`).

Rollback

Single-file revert of `.github/workflows/build-test-windows.yml`.

[Grantim]

comment seems excessively large, can it be simplified?

[Fedr]

Shortened to three lines in fb6f4ca.