[M2-SPRITE-02] MSVC fix: explicit size_t -> u32 cast in submit (C4267)

[offdev]

Context

The M2-SPRITE-02 merge (commit 08e96d3) failed the merge-lane CI on the Windows x64 (MSVC 2022) job only — run 37189830435:

sprite_renderer.cpp(557,45): error C2220: the following warning is treated as an error
sprite_renderer.cpp(557,45): warning C4267: 'initializing': conversion from 'size_t' to 'uint32_t', possible loss of data

The PR lane runs Windows only under the ci:windows label, so MSVC had not compiled this step's code before the merge.

Root cause

const std::uint32_t n = batcher.frameCount(); — SpriteBatcher::frameCount() returns std::size_t; on the 64-bit MSVC toolchain the implicit narrowing is C4267, and the job builds with warnings-as-errors.

Fix

One explicit static_cast<std::uint32_t> (the house style for the size_t → u32 boundary — the same cast the instance pack uses two lines below). Lossless by invariant: the frame count is always ≤ the batcher's u32 capacity (kSpriteBatcherMaxCapacity), so no value is ever truncated.

Audit of the rest of the step's MSVC-unverified code

sprite_renderer.h, sprite_renderer.cpp, sprite_draw_tests.cpp, and the GlContext::frameBuffer() additions were scanned for every implicit narrowing (every .size()/frameCount()/GL-size source): no other C4267/C4244 trigger remains — everything else is already an explicit static_cast or a comparison.

Verification

• Canonical tree: rebuild warning-free, ctest -R sprite_draw green (12/12).
• Windows: the ci:windows label is applied to this PR so the MSVC 2022 job runs on the PR lane before merge.
• No behavior change (the cast is identity on every value the batcher can produce); no API change; laige-api.json unaffected (no signature change).

[offdev]

CI status

• Windows x64 (MSVC 2022): this fix's purpose — the first CI run of the branch (37192995927) started before the ci:windows label was applied, so the job was skipped; the full rerun (in progress) re-evaluates the labels and will run it.
• Linux x64 (clang++): first run failed ONLY on the pre-existing iso_depthkey_rebuild budget gate (M2-ISO-02, IsoDepthTableBudget.TenThousandDirtyCells, fp32_pinned backend) — the documented zero-margin coin-flip (CI clang 18.1.3 -O0 sits exactly at the 0.2 ms target; it has flaked on unrelated PRs before, e.g. M2-SPRITE-01). Not a regression of this change (the change is a one-line cast in sprite_renderer.cpp, which compiled clean on the clang lane). Per the standing decision: rerun, do not touch the budget target.
• All other jobs (linux-gcc, ASan+UBSan, TSan, detcheck, lints, api-drift) green.

[offdev]

CI resolved

• Windows x64 (MSVC 2022): SUCCESS on run 37194313066 (empty CI-trigger commit 5d1fa7d fired a fresh pull_request event, so the job ran under the current ci:windows label). The C4267 fix is verified on MSVC.
• Linux lanes: SUCCESS on run 37192995927 (gcc, clang, ASan+UBSan, TSan) — the clang lane's second iso_depthkey_rebuild failure (both backends ~0.267 ms vs the 0.2 ms target, a slow shared runner — the change doesn't touch M2-ISO-02 code) passed on the failed-job rerun.
• macOS: verified on the merge-lane run 37189830435 (both AppleClang jobs succeeded there); PR-lane skips are the label selector, not a failure.
• Lint / determinism / API-drift jobs: green on both runs.

All P0 lanes are now green on this branch — ready for merge.