Enforce strict spin lifecycle — prevent starting next spin until previous completes (critical)

[WERSIT35]

Summary

The spin lifecycle currently allows input/behaviors that can start a new spin before the previous spin has fully completed. The feature that speeds up a spin by pressing again is unreliable and several conditions need strict prioritization. It is mandatory that the game never starts a new spin until the previous spin finishes successfully.

Steps to reproduce

1. Start a spin.
2. While the spin is running press the spin button (attempt speed-up).
3. Observe timing where repeated presses or certain mid-spin events cause the next spin to start or the state machine to enter an inconsistent phase.

Observed behavior

• Next spin may start prematurely or UI/state becomes inconsistent.
• Speed-up request handling is unreliable and may be lost or processed out of order.

Expected behavior (MANDATORY)

• The engine must enforce a strict spin lifecycle/state machine where a spin goes through ordered phases (examples below) and remains atomic: the next spin cannot start until the current spin enters the final Completed state.
• Speed-up should be implemented as a state transition or flag within the same spin lifecycle (accelerate the current spin) — it must not enqueue or start a separate spin.

Recommended spin lifecycle (example)

• Idle -> SpinStart -> Spinning -> AccelerationRequested? -> Resolve -> Tumble -> Payout -> Completed -> Idle

Implementation notes / suggested fixes

• Implement an explicit state machine in the client (and server where applicable), with a single source-of-truth state (round-orchestrator.ts on platform; backend/server.js for MVP).
• Disable/ignore spin input while state != Idle. If speed-up is allowed, it should set a flag on the current state rather than enqueueing a new spin.
• Ensure server-side also rejects/conservatively handles concurrent spin requests for the same session (idempotency / sequence check).
• Add unit / integration tests simulating rapid input to assert that only one spin completes at a time and that speed-up results in acceleration of the current spin.
• Carefully order priorities for events: resolve results first, apply tumble and payout, then mark Completed. Only after Completed may Idle accept a new spin.

Files/areas to inspect

• round-orchestrator.ts, round-ledger.service.ts, authoritative-resolver.ts (platform)
• backend/server.js (MVP path)
• client spin handling code (client/main.js, client UI spin button handler)

Impact

Critical — allows state corruption, incorrect game outcomes, or unfair play if spins overlap. This must be fixed before release.