Fix: SendCommand raced Tick against the command, corrupting state on WebPlayer

[alexwarren]

Summary

• SendCommand launched Tick(0) and HandleCommandAsyncInternal concurrently (both fire-and-forget) whenever elapsedTime > 0. Both read/mutate the same Elements/Fields collections, so on WebPlayer's real thread pool this could corrupt a Dictionary mid-turn ("Operations that change non-concurrent collections must have exclusive access"), which then throws on every subsequent access until the process restarts. WasmPlayer's single-threaded runtime can't manifest true corruption, so it looked fine there.
• This race predates Fix: timer created inside wait/pause/ask/menu callback never fires #1835 but was rarely reachable — Fix: timer created inside wait/pause/ask/menu callback never fires #1835 restored elapsed-time tracking after wait/pause/ask/menu resolve, so elapsedTime > 0 became the common case for any wait-heavy game, turning a latent race into a reliably reproducible one (reported against the game "Oracle Feels Confused", which leans heavily on wait { }).
• Fix: Tick(0) now runs to completion before the command starts, instead of racing it.

Test plan

• New regression test SendCommand_ElapsedTimeTriggersTimer_TimerRunsBeforeCommand (tests/EngineTests/CallbackTests.cs), backed by a new timer/command pair in callbacktest.aslx
• Confirmed the test fails on the pre-fix code (command output landed before the timer's) and passes with the fix
• Full solution test suite passes (dotnet test --configuration Release, 319/319)

🤖 Generated with Claude Code