ui/phase-14: rename planet end-to-end + order read-back

Wires the first end-to-end command through the full pipeline:
inspector rename action → local order draft → user.games.order
submit → optimistic overlay on map / inspector → server hydration
on cache miss via the new user.games.order.get message type.

Backend: GET /api/v1/user/games/{id}/orders forwards to engine
GET /api/v1/order. Gateway parses the engine PUT response into the
extended UserGamesOrderResponse FBS envelope and adds
executeUserGamesOrderGet for the read-back path. Frontend ports
ValidateTypeName to TS, lands the inline rename editor + Submit
button, and exposes a renderedReport context so consumers see the
overlay-applied snapshot.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -371,11 +371,15 @@ 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
-three message types `user.games.command`, `user.games.order`,
-`user.games.report` (FB schemas in `pkg/schema/fbs/{order,report}`,
-encoders in `pkg/transcoder`). Backend never touches FlatBuffers and
-never re-interprets the JSON beyond rebinding the actor field from
-the runtime player mapping (clients never carry a trusted actor).
+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`).
+`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
+from the report. Backend never touches FlatBuffers and never
+re-interprets the JSON beyond rebinding the actor field from the
+runtime player mapping (clients never carry a trusted actor).
 
 Container state is owned by `backend/internal/runtime`:
 

docs/FUNCTIONAL.md

@@ -606,13 +606,16 @@ not duplicated here.
 
 ### 6.2 Backend's role: pass-through with authorisation
 
-The signed authenticated-edge pipeline for in-game traffic uses three
+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.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 reply.
+`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
+reply. `user.games.order.get` is the read-back companion to
+`user.games.order`: clients use it to hydrate the local order draft
+after a cache loss (fresh install, cleared storage, new device).
 
 For every in-game endpoint the user surface acts as an authorised
 pass-through to the engine container. Backend:

docs/FUNCTIONAL_ru.md

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