feat(game): canonical gameId in POST /api/v1/admin/init

Engine no longer mints its own game UUID. The orchestrator (backend)
generates the game UUID at game-create time and passes it in the
admin/init request body as the required `gameId` field, so the value
that names the engine container and host bind-mount directory also
ends up inside the engine's state.json.

The engine rejects the zero UUID with 400 and any init that conflicts
with an existing state.json with 409 (a second init on the same gameId
is also a conflict; full idempotency is not part of the contract).

Updates rest.InitRequest, openapi.yaml (schema + 409 response),
controller.GenerateGame/NewGame/buildGameOnMap signatures, the engine
HTTP handler/executor, the backend runtime worker, and the relevant
unit and contract tests. Documentation in game/README.md,
docs/ARCHITECTURE.md, backend/README.md, and backend/docs/{runtime,flows}.md
is updated in the same patch.

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

docs/ARCHITECTURE.md

@@ -402,6 +402,14 @@ Container state is owned by `backend/internal/runtime`:
   always `http://galaxy-game-{game_id}:8080`.
 - Engine probes (`/healthz`) feed `runtime` health observations and turn
   generation status.
+- Canonical game identity is owned by backend. The `game_id` allocated
+  at game-create time is reused everywhere downstream: it names the
+  container, the host bind-mount directory, and is passed verbatim to
+  the engine in `POST /api/v1/admin/init`'s `gameId` field. The engine
+  persists this value into `state.json` and echoes it in every
+  `StateResponse`; the engine never mints its own game UUID. A zero
+  UUID or a conflict with an existing `state.json` is rejected by the
+  engine (`400` / `409` respectively).
 
 ## 10. Geo Profile (reduced)