v0.10.0 fix to engine game state mgmt, client and web ui updates to match

doc/api.md

@@ -156,7 +156,7 @@ Returns current game state.
 
 **Long-polling support:**
 Add query parameters for real-time updates:
-- `wait=true` - Enable long-polling (waits up to 25 seconds)
+- `wait=true` - Enable long-polling (waits up to 30 seconds)
 - `moveCount=N` - Last known move count
 
 Returns immediately if game state changed, otherwise waits for updates:
@@ -167,7 +167,7 @@ GET /games/{gameId}?wait=true&moveCount=5
 Response includes all game data. Compare `moves` array length to detect changes.
 
 **Timeout behavior:**
-- Returns current state after 25 seconds even if no changes
+- Returns current state after 30 seconds even if no changes
 - Client disconnection cancels wait immediately
 - Game deletion notifies all waiting clients
 
@@ -242,4 +242,4 @@ Tokens are HS256-signed JWTs valid for 7 days. Include in Authorization header:
 Authorization: Bearer <token>
 ```
 
-Token claims include `sub` (user ID), `username`, `email`, and `exp` (expiration).
+Token claims include `sub` (user ID), `username`, `email`, and `exp` (expiration).

doc/architecture.md

@@ -12,7 +12,7 @@ Central command handler containing business logic. Single `Execute(Command)` ent
 In-memory state storage with authentication support. Thread-safe game map protected by RWMutex. Manages game lifecycle, snapshots, player configuration, user accounts, and JWT token generation. Coordinates with storage layer for persistence of both games and users.
 
 #### Long-Polling Registry (`internal/service/waiter.go`)
-Manages clients waiting for game state changes via HTTP long-polling. Tracks move counts per client, sends notifications on state changes, enforces 25-second timeout. Non-blocking notification pattern handles slow clients gracefully. Coordinates with service layer for game updates and deletion events.
+Manages clients waiting for game state changes via HTTP long-polling. Tracks move counts per client, sends notifications on state changes, enforces 30-second timeout. Non-blocking notification pattern handles slow clients gracefully. Coordinates with service layer for game updates and deletion events.
 
 #### Authentication Module (`internal/service/user.go`, `internal/http/auth.go`)
 - **Password Hashing**: Argon2id for secure password storage
@@ -72,7 +72,7 @@ SQLite persistence with async writes for games, synchronous writes for authentic
 1. Client sends `GET /games/{id}?wait=true&moveCount=N`
 2. Handler creates context from HTTP connection
 3. Registers wait with WaitRegistry using game ID and move count
-4. If game state unchanged, blocks up to 25 seconds
+4. If game state unchanged, blocks up to 30 seconds
 5. On any game update, NotifyGame sends to all waiters
 6. Returns immediately with current state
 7. Client disconnection cancels wait via context
@@ -210,4 +210,4 @@ moves (
 - JWT secret rotates on restart (or fixed in dev mode)
 - User IDs use UUIDs with collision detection
 - Transactions ensure data consistency
-- Case-insensitive queries prevent duplicate accounts
+- Case-insensitive queries prevent duplicate accounts

doc/client.md

@@ -135,7 +135,7 @@ chess > delete <gameId>      # Delete specific game
 ```
 
 #### `poll` / `p`
-Long-poll for game updates (waits up to 25 seconds).
+Long-poll for game updates (waits up to 30 seconds).
 ```
 chess > poll
 ```
@@ -290,4 +290,4 @@ The client architecture follows a command pattern with:
 - **Display**: Terminal formatting utilities
 - **Commands**: Modular command handlers
 
-Extensions can add new commands by registering handlers in the appropriate command group (game, auth, debug).
+Extensions can add new commands by registering handlers in the appropriate command group (game, auth, debug).