ui/phase-25: backend turn-cutoff guard + auto-pause + UI sync protocol

Backend now owns the turn-cutoff and pause guards the order tab
relies on: the scheduler flips runtime_status between
generation_in_progress and running around every engine tick, a
failed tick auto-pauses the game through OnRuntimeSnapshot, and a
new game.paused notification kind fans out alongside
game.turn.ready. The user-games handlers reject submits with
HTTP 409 turn_already_closed or game_paused depending on the
runtime state.

UI delegates auto-sync to a new OrderQueue: offline detection,
single retry on reconnect, conflict / paused classification.
OrderDraftStore surfaces conflictBanner / pausedBanner runes,
clears them on local mutation or on a game.turn.ready push via
resetForNewTurn. The order tab renders the matching banners and
the new conflict per-row badge; i18n bundles cover en + ru.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/FUNCTIONAL.md

@@ -635,18 +635,40 @@ validity and ordering of in-game decisions. Gateway needs to know
 the typed FB shape only to transcode the wire format; the per-command
 semantics live in the engine.
 
-### 6.3 Turn cutoff
+### 6.3 Turn cutoff and auto-pause
 
 A running game continuously alternates between a command-accepting
-window and a generation phase. The transition `running →
-generation_in_progress` is the cutoff: any command or order that
-arrives after the cutoff is rejected by backend before forwarding,
-because the engine no longer accepts writes for the closing turn.
-After generation finishes, backend re-opens the window for the next
-turn.
+window and a generation phase, driven by the cron expression stored
+in `runtime_records.turn_schedule`. The backend scheduler
+(`backend/internal/runtime/scheduler.go`) wraps each engine
+`/admin/turn` call between two `runtime_status` flips:
+
+- Before the engine call: `running → generation_in_progress`.
+  The user-games command/order handlers
+  (`backend/internal/server/handlers_user_games.go`) consult the
+  per-game runtime record on every request and reject with
+  HTTP 409 + `code = turn_already_closed` while the runtime sits in
+  `generation_in_progress`. The error envelope mirrors backend's
+  standard `httperr` shape: `{"error": {"code":
+  "turn_already_closed", "message": "..."}}`.
+- After a successful tick: `generation_in_progress → running`.
+  The order window re-opens for the new turn and the next
+  scheduled tick continues normally.
+- After a failed tick (`engine_unreachable` /
+  `generation_failed`): the lobby's `OnRuntimeSnapshot` flips the
+  game from `running` to `paused` and publishes a `game.paused`
+  push event (see §6.5). The order handlers reject with HTTP 409
+  + `code = game_paused` until an admin resume succeeds.
 
 `force-next-turn` (admin) schedules a one-shot extra tick that
-advances the next scheduled turn by one cron step.
+advances the next scheduled turn by one cron step; the same
+status-flip and rejection rules apply.
+
+Clients distinguish the two rejections by `code`:
+`turn_already_closed` means "wait for the next `game.turn.ready`
+and resubmit", whereas `game_paused` means "wait for an admin
+resume". The web client implements both reactions in
+`ui/docs/sync-protocol.md`.
 
 ### 6.4 Reports
 
@@ -672,13 +694,24 @@ runtime status, per-player stats). The engine's "game finished"
 report drives the `running → finished` transition ([Section 3.5](#35-cancellation-and-finish))
 and triggers Race Name Directory promotions ([Section 5](#5-race-name-directory)).
 
-Among the `game.*` notification kinds, `game.turn.ready` is wired:
-`lobby.Service.OnRuntimeSnapshot` (`backend/internal/lobby/runtime_hooks.go`)
-emits one intent per advancing `current_turn`, addressed to every
-active membership of the game, with idempotency key
-`turn-ready:<game_id>:<turn>` and JSON payload `{game_id, turn}`. The
-catalog routes the intent through the push channel only; email is
-deliberately omitted to avoid per-turn spam.
+Among the `game.*` notification kinds, `game.turn.ready` and
+`game.paused` are wired:
+
+- `game.turn.ready` —
+  `lobby.Service.OnRuntimeSnapshot` (`backend/internal/lobby/runtime_hooks.go`)
+  emits one intent per advancing `current_turn`, addressed to every
+  active membership of the game, with idempotency key
+  `turn-ready:<game_id>:<turn>` and JSON payload `{game_id, turn}`.
+- `game.paused` — the same hook publishes one intent per transition
+  into `paused` driven by an `engine_unreachable` /
+  `generation_failed` runtime snapshot, addressed to every active
+  membership, with idempotency key `paused:<game_id>:<turn>` and
+  JSON payload `{game_id, turn, reason}`. The runtime status that
+  triggered the transition is carried as `reason` so the UI can
+  differentiate the copy in a future revision.
+
+Both kinds route through the push channel only; email is
+deliberately omitted to avoid per-turn / per-pause spam.
 
 The remaining `game.*` kinds (`game.started`, `game.generation.failed`,
 `game.finished`) and `mail.dead_lettered` are reserved without a