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>

game/openapi.yaml

@@ -7,13 +7,14 @@ info:
 
     The service hosts a single game instance and exposes endpoints for game
     initialization, turn advancement, game-state queries, player reports, and
-    batched player command execution.
+    player order submission.
 
     Transport rules:
     - request bodies are JSON
-    - `PUT /api/v1/command` is rate-limited to one concurrent execution;
-      requests that cannot acquire the execution slot within 100 ms receive
-      `504 Gateway Timeout`
+    - operations that mutate the persisted game state are serialised engine-wide
+      to one at a time; such a request blocks until the in-flight mutation
+      finishes and receives `503 Service Unavailable` if its context is
+      cancelled while it is still waiting
     - `501 Not Implemented` is returned without a body when the game has not
       been initialized
     - request-binding validation errors return `400` with `{"error": "message"}`
@@ -141,33 +142,6 @@ paths:
           $ref: "#/components/responses/ValidationError"
         "500":
           $ref: "#/components/responses/InternalError"
-  /api/v1/command:
-    put:
-      tags:
-        - PlayerActions
-      operationId: executeCommands
-      summary: Execute a batch of player commands
-      description: |
-        Applies one or more game commands for the specified actor. Serialized
-        to one concurrent execution; requests that cannot acquire the execution
-        slot within 100 ms return `504 Gateway Timeout`. Returns `202 Accepted`
-        with no body on success. Reserved for future use; player order
-        submissions go through `/api/v1/order`.
-      requestBody:
-        required: true
-        content:
-          application/json:
-            schema:
-              $ref: "#/components/schemas/CommandRequest"
-      responses:
-        "202":
-          description: All commands accepted.
-        "400":
-          $ref: "#/components/responses/ValidationError"
-        "504":
-          description: Command execution slot not acquired within 100 ms.
-        "500":
-          $ref: "#/components/responses/InternalError"
   /api/v1/order:
     put:
       tags: