[M1-SYS-03] Fix macOS/Windows CI: volatile compound-assign error; platform-dependent lastMs assertion

[offdev]

The windows-msvc, macos-intel, and macos-arm64 jobs are red on the M1-SYS-03 merge (run 82). Two independent, platform-sensitive defects, both in tests/laige-sim/system_timing_tests.cpp:

1. macOS Intel (macos-14, AppleClang 15) — build error

system_timing_tests.cpp:125: error: compound assignment to object of
volatile-qualified type is deprecated [-Werror,-Wdeprecated-volatile]

The P1152R2 volatile deprecation (compound assignment to a volatile-qualified type) is diagnosed by AppleClang 15 and fatal under the engine policy's -Werror, while the other P0 job toolchains do not diagnose it (Clang 18 on ubuntu-24.04, AppleClang 16 on macos-15, MSVC 2022) — so only macos-intel failed to build. The burn-loop sink is now updated with an ordinary assignment (gBurnSink = gBurnSink + 1;), the pattern already established in budget_harness_tests.cpp's Spin(). The volatile read-modify-write remains, so the loop still defeats elimination.

2. Windows + macOS arm64 — flaky lastMs assertion

SystemTiming.HealthyTicksLogNothingAndTrackStats:
EXPECT_GT(st.value().lastMs, 0.0) — actual: 0 vs 0

A noop system runs in tens of nanoseconds; on platforms whose steady_clock tick is coarser than that (the start and end reads land on the same tick) the measured run time is exactly 0.0 ms — a legitimate sub-resolution reading (wall-clock resolution is platform-sensitive; ARCH-009), not a failure state. The assertion was process-state-dependent: the unfiltered laige-sim_tests entry failed on Windows while the filtered system_timing entry passed, and vice versa on arm64 — the same flake class as the pre-M1-ECS-05 churn cost checks fixed in #20. The lower bound becomes EXPECT_GE(st.value().lastMs, 0.0); the tracked-state property is already pinned by the runs counter, and the upper bound (< 1.0 ms, under the 1 ms budget) is unchanged.

Docs + manifest

• system.h (SystemTimingStats::lastMs, SystemTimingRecord::lastMs) and docs/api/system_timing.md now state that a run shorter than the platform's steady_clock tick measures as exactly 0.0 ms and must not be treated as "not measured" (DOC-006/007).
• laige-api.json regenerated: manifest entries carry declaration line numbers, and the system.h comment additions shifted four declarations (LAIGE_SYSTEM, SystemTimingStats::{lastMs,warns,errors}).

Verification

Local (g++ 16.2 / clang 22.1, Debug trees): full ctest suite 43/43 on both toolchains; include-lint OK; laige-api-scanner --check up to date.

CI:

• PR run (default Linux lane): all seven Linux jobs plus the three tooling jobs green.
• Full P0 matrix dispatched on this branch via workflow_dispatch (run https://github.com/offdev/laige-cpp/actions/runs/34886215741): all 10 jobs green, including the three previously red jobs — Windows x64 (MSVC 2022), macOS Intel (AppleClang), and macOS arm64 (AppleClang).
• The ci:windows label stays on the PR so any further push to this branch re-verifies the Windows P0 job; the merge to master re-runs the full matrix via ci.yml regardless of labels.