[M1-HEAD-01] Fix Windows CI: MSVC C4996 fopen fatal under /WX in laige-run

[offdev]

What is broken

The windows-msvc job (merge matrix) is red on the M1-HEAD-01 merge (run 34958290344). Two independent, both Windows-only defects:

1. Build error — MSVC C4996 fopen fatal under /WX

laige-run.cpp(119,26): warning C4996: 'fopen': This function or variable may be unsafe.
laige-run.cpp(119,26): error C2220: the following warning is treated as an error

MSVC's CRT deprecates plain fopen (C4996), fatal under the engine policy's /W4 /WX (NFR-8.10, CORE-010). laige-run.cpp is new in M1-HEAD-01, so this is the first Windows build of the binary.

Fix: the config-file open now uses the portable platform boundary already established in logging.cpp (the M0-CORE-02 file sink), laige-bench.cpp, and the test suites: under _MSC_VER, _fsopen(path, mode, _SH_DENYNO) — the CRT's documented way to open with plain-fopen sharing semantics. fopen_s is deliberately not used: it opens with the _SH_SECURE sharing mode, which denies re-opening of the file while it is held (the windows-msvc CI runs of M0-CORE-02 read back an empty file for exactly that reason — documented in logging.cpp). No behavioral change.

2. Test failure — EngineRun.HeadlessFramePathAllocatesNothing (allocs=4 vs 3)

Once the build was fixed, the same job failed the zero-allocation headless-run test: the measured run_headless(3, 1) window allocates 4 heap objects on windows-msvc, 3 on every other P0 platform.

Root cause (established by staged allocation probes run on the CI runner): the extra allocation lands between the entry of Logger::shutdown() and the declaration of its local std::vector<RateEntry> pending; — and it is per declaration, per call, for any element type (empty vector<int> / vector<string> / a second vector<RateEntry> each added exactly one; the idempotent second shutdown() call allocated the same four again). That signature is the MS STL's checked-iterator debug mode: CMake's default MSVC Debug flags define _DEBUG, which makes the STL default to _ITERATOR_DEBUG_LEVEL=2, where every STL container instance gets a heap-allocated iterator-proxy object in its constructor. The engine's window contains exactly one container declaration (the logger's shutdown local), so Windows measures 4 while the other P0 platforms — which compile without checked iterators by default — measure the documented 3.

Fix: laige_apply_engine_policy() now defines _ITERATOR_DEBUG_LEVEL=0 for MSVC targets (PRIVATE, like the existing _HAS_EXCEPTIONS=0), so the Windows Debug build measures the same allocation behavior as the rest of the P0 matrix. The proxies are an STL debug aid, not engine behavior — allocated in container setup, never on hot paths — so no engine behavior changes; the zero-allocation invariants now hold identically on every P0 platform.

Verification

• Local: zero-warning gcc/clang builds, 47/47 ctest (incl. laige_run_smoke, status=ok).
• CI: this PR carries the ci:windows label, so the windows-msvc job runs both previously failing steps.