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/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: