refactor(game): lock-free storage, remove /command, flatten engine wrapper

Three-stage refactor of the game-engine plumbing (game logic untouched):

Stage 1 — lock-free persistence + admin serialisation. Remove the file
lock from repo/fs (the .lock file, the Read/Write-vs-*Safe duality and the
dead ReadSafe polling) and replace the two-step rename with a single atomic
rename so concurrent reads are torn-free without a lock. Serialise the
state-mutating admin writers (init/turn/banish) with one shared router
LimitMiddleware, rewritten to block on the request context instead of a
racy shared 100ms timer.

Stage 2 — remove the obsolete immediate-command path end to end. Players
submit through PUT /api/v1/order; the legacy PUT /api/v1/command path is
deleted across game (route, handler, 24 command factories, Ctrl), backend
(Commands handler/route, engineclient.ExecuteCommands), gateway (dispatch +
executeUserGamesCommand + routing entry), the FlatBuffers/model contract
(UserGamesCommand[Response]) and transcoder, plus every affected
OpenAPI/README/FUNCTIONAL/ARCHITECTURE doc. The integration proxy test is
converted to the order path.

Stage 3 — flatten the REST->engine wrapper. Replace the executor adapter,
the controller package functions and RepoController with one concrete
controller.Service; drop the single-implementation Repo and Storage
interfaces (repo.Repo / fs.FS are now concrete). Handlers depend on a thin
handler.Engine seam and own the domain->REST projection; storage is
resolved once at startup instead of per request.

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

docs/ARCHITECTURE.md

@@ -375,9 +375,9 @@ Authenticated client traffic for in-game operations crosses three
 serialisation boundaries: signed-gRPC FlatBuffers (client ↔ gateway),
 JSON over REST (gateway ↔ backend), and JSON over REST again
 (backend ↔ engine). Gateway owns the FB ↔ JSON transcoding for the
-four message types `user.games.command`, `user.games.order`,
-`user.games.order.get`, `user.games.report` (FB schemas in
-`pkg/schema/fbs/{order,report}`, encoders in `pkg/transcoder`).
+three message types `user.games.order`, `user.games.order.get`,
+`user.games.report` (FB schemas in `pkg/schema/fbs/{order,report}`,
+encoders in `pkg/transcoder`).
 `user.games.order.get` reads back the player's stored order for a
 given turn — paired with the POST `user.games.order` so the client
 can hydrate its local draft after a cache loss without re-deriving

docs/FUNCTIONAL.md

@@ -619,10 +619,10 @@ not duplicated here.
 
 ### 6.2 Backend's role: pass-through with authorisation
 
-The signed authenticated-edge pipeline for in-game traffic uses four
-message types on the authenticated surface — `user.games.command`,
-`user.games.order`, `user.games.order.get`, `user.games.report` —
-each with a typed FlatBuffers payload. Gateway transcodes the FB
+The signed authenticated-edge pipeline for in-game traffic uses three
+message types on the authenticated surface — `user.games.order`,
+`user.games.order.get`, `user.games.report` — each with a typed
+FlatBuffers payload. Gateway transcodes the FB
 request into the JSON shape backend expects, forwards over plain
 REST to the corresponding `/api/v1/user/games/{game_id}/*` endpoint,
 then transcodes the JSON response back into FB before signing the
@@ -671,7 +671,7 @@ in `runtime_records.turn_schedule`. The backend scheduler
 `/admin/turn` call between two `runtime_status` flips:
 
 - Before the engine call: `running → generation_in_progress`.
-  The user-games command/order handlers
+  The user-games 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

docs/FUNCTIONAL_ru.md

@@ -637,9 +637,9 @@ Wire-формат команд, приказов и отчётов — собс
 ### 6.2 Роль backend: pass-through с авторизацией
 
 Подписанный конвейер аутентифицированного edge для in-game-трафика
-использует четыре message types на аутентифицированной поверхности —
-`user.games.command`, `user.games.order`, `user.games.order.get`,
-`user.games.report` — у каждого типизированный FlatBuffers-payload.
+использует три message types на аутентифицированной поверхности —
+`user.games.order`, `user.games.order.get`, `user.games.report` —
+у каждого типизированный FlatBuffers-payload.
 Gateway транскодирует FB-запрос в JSON-форму, которую ждёт backend,
 форвардит её REST'ом в соответствующий
 `/api/v1/user/games/{game_id}/*` endpoint, после чего транскодирует