[M1-DET-03] Fix macOS/Windows CI: replay tool strncpy C4996; exact tick count for bounded laige-run; CRLF-tolerant replay check script

[offdev]

Fixes the three non-Linux P0 jobs of the latest master CI run (eaa0705).

Root causes

1. Windows build failure — tools/replay/laige-replay.cpp:438 calls std::strncpy, C4996, fatal under the engine's /WX policy (the new M1-DET-03 tool was the only TU that errored; everything else compiled).
2. macOS arm64 + Intel test failures — replay_smoke and replay_expect_truncated record via laige-run --ticks 32, which drove the bounded run with the default catch-up budget (5). The run_headless contract allows a late frame to complete several due ticks at once, ending the run up to budget - 1 ticks over the target; on the macOS runners a paced sleep overshoots the 16.67 ms tick interval, so the run completed 33 ticks and the log carried 34 hash lines (expected frames=32 hash_lines=33, got frames=33 hash_lines=34).
3. Windows latent (masked by the build failure) — the replay check script parses captured child output line-by-line; on Windows child streams are CRLF and a trailing \r would break the per-line hash-line contract and the perturb-derive hash validation (CMake-version-dependent capture behavior).

Fixes

• strncpy → memcpy of exactly 16 bytes (source is guaranteed 16 hex digits + NUL by parseBaselineLine/formatHex16); no other C4996-class call remains in the TU.
• laige-run drives bounded runs (--ticks N, N > 0) with frame budget 1: each frame runs at most one tick, so the run lands exactly on N under any cadence (a late frame drops its extra due tick — dropped_ticks — it never overshoots). The EngineRun.BoundedRunCompletesExactly precedent and the M1-DET-02 fix (b075ca1) for the same failure class. The server form (N = 0) keeps the default catch-up budget. The recorded tick count is now platform-stable, which the record → replay pipeline and the replay tests' fixed 33-hash-line contract rely on.
• The replay check script normalizes captured stdout/stderr CRLF → LF before any line parsing (the detcheck "optional trailing \r" tolerance at the capture boundary; no-op on already-LF content).
• Docs: docs/api/engine.md (--ticks N exact-count contract) and docs/api/replay.md (platform-stable recorded tick count), plus the shared-setup comment in tests/replay/CMakeLists.txt.

Verification

• Local (g++ 16.2 + clang++ 19, Debug = the linux-gcc/linux-clang job configs): warning-free builds under -Wall -Werror; ctest 67/67 in both trees.
• laige-run --ticks 32 ×3 and --ticks 500 ×2 all land exactly on the requested count; record → replay ×3 gives exactly 33 hash lines and frames=32 hash_lines=33 result=ok every time.
• CRLF path verified end-to-end by driving the real template through a fake tool emitting CRLF stdout/stderr (smoke/truncated/perturbed shapes all pass; the per-line contract provably fails on a CR-suffixed line without the normalization).
• Windows cannot be run from this sandbox: the memcpy fix follows the already-Windows-verified _fsopen precedent, and the merge workflow (ci.yml) re-runs all P0 jobs on merge.

CI label

Labeled ci:macos (the observed failure, both macOS jobs). The Windows job runs on the merge — relabel to ci:windows if you want it pre-verified before merging.