Fix the seventh-round "never-ending dice stacking" bug (locked dice past 10 + dropped-broadcast desync)

[radiantnode]

What & why

Chases down the reported "seventh round" bug where a player's board kept stacking locked dice past 10 and the round never resolved for them. Investigation turned up two distinct client-side defects (the server is correct throughout — locked never exceeds 10 and rounds always advance). Both are fixed here, plus a belt-and-suspenders resync guard.

1. Locked dice stacking past 10 (animations.js)

The locked-dice zone was rebuilt by blindly appending a delta (prevMatchedCount → newMatched.length) on every roll. Under the reveal/rebuild races a fast-tapped game produces, the live zone's child count drifts from the prevMatchedCount basis, so the delta over-appends and the pile grows past 10. The pop now reconciles the zone to exactly the snapshot's matched dice (trim any excess, animate only the genuinely-missing dice), and a pop whose round has already advanced bails instead of dropping stale dice into the next round.

2. Dropped-broadcast desync — the real "frozen board" (state.js, game-render.js, animations.js)

On a flaky connection a client can miss the round_won and the round-advance broadcast. The server moves on; the client stays on the old round. Its next roll is processed server-side in the new round, but the reveal animated that response in place onto the stale board — keeping the previous round's locked dice and stacking the new target on top (e.g. matched zone [1,1,1,1,1,2,2]), with no win overlay. This matches a real report: old 1s stayed locked, new 2s piled on, and the player had to wait for the next round to resync.

Fix: track the round each board was built for (state.boardRound), and hard-rebuild in updateDiceInPlace when a reveal is for a different round. The client now catches up on its next roll, not just on the next broadcast it happens to receive.

3. Catch-up guard (net.js)

Belt-and-suspenders for a client that's wedged or simply stops rolling: a state frame for a round ahead of the one on screen is now applied immediately (reset the roll machine + route) instead of being stashed behind an in-flight roll. There's no longer any path where a client stays parked on an old round while the server moves on — it resyncs on the next frame it hears, whichever comes first.

How it was verified (two Playwright clients, mobile viewport)

• Stacking: reproduced the matched zone hitting 14 dice; post-fix it stays capped at 9 across 20+ rounds.
• Dropped-broadcast desync: deterministically dropped the round_won + advance frames on one client, then rolled. Pre-fix the matched zone showed [1,1,1,1,1,2,2] (stale ones + stacked twos); post-fix it rebuilds to a clean round-2 board ([2], then 2/3/4 twos as normal). Same-round in-place reveals unaffected.
• Catch-up guard: forced a client into the wedged state (awaitingAck stuck, pending state stashed) on the old round and had it not roll — it resynced to the new round the instant the opponent's next broadcast arrived.
• Regression: a normal win still shows the loser overlay and advances one round cleanly.
• tsc -p jsconfig.json passes on the merged tree.

Commits

• Fix locked dice stacking past 10 in the reveal animation
• Resync a stale board when a round-advance broadcast is lost
• Force-apply a round-ahead state frame instead of stashing it

(Includes a merge of origin/main.)

🤖 Generated with Claude Code

---

Generated by Claude Code