Per-game 100ms clock timers add up at scale

Summary

For every game with a time control, Game.ts runs setInterval(..., 100)
to push clock updates (TIME_UPDATE) to both players. At scale this is
system-wide overhead that grows linearly with concurrent timed games:
500 timed games = 5,000 timer callbacks/sec, each doing 2 JSON.stringify

• 2 ws.send().

Note

Load tests in load-tests/ws-load-test.ts currently use timeControl: null
specifically to isolate this cost from the matchmaking/routing cost
Real-world games are mostly timed, so this cost is additive on top of what
was measured.

Proposed direction

Replace per-game intervals with a single shared ticking loop (e.g. one
setInterval that iterates active timed games and only sends updates that
actually changed, or batches multiple games' updates per tick). This changes
timing precision slightly, so worth confirming acceptable drift before
implementing.

Start in Game.ts by tracing the per-game setInterval that sends TIME_UPDATE to both players, then review load-tests/ws-load-test.ts to understand the current workload assumptions. Replace the per-game timers with a shared approach, and confirm that timing drift remains acceptable while reducing timer and message overhead for concurrent timed games.