Stage 17: bake decisions into PLAN, ARCHITECTURE, FUNCTIONAL(+ru), UI_DESIGN, READMEs; mark stage done

- PLAN: Stage 17 Refinements entry + caveats resolved summary + tracker done
- ARCHITECTURE §7 (move-number robot timing, composed variant-aware names), §10 (move event to the actor too), §11 (game_move_duration metric + offline admin per-user analytics), §14 (current branch model, path-conditional CI + gate, connector liveness)
- FUNCTIONAL(+ru): robot draws language-appropriate names
- UI_DESIGN: screen transitions, Telegram theme/nav, ad-banner accent, players plaque + history drawer
- backend README: robot timing/names refinements

backend/README.md

@@ -46,13 +46,13 @@ but their live delivery, and all REST endpoints, arrive with the `gateway`
 
 Stage 5 adds the robot opponent (`internal/robot`). A pool of durable accounts —
 each a `kind='robot'` identity, provisioned at startup with chat and friend
-requests blocked — backs a human-like name pool. A background driver plays the
+requests blocked — backs human-like, per-language composed names. A background driver plays the
 robot's moves through the public game API as an ordinary seated player (so only
 `internal/engine` imports the solver): it decides once per game whether to play to
-win (≈ 40%), targets a small score margin, and times its moves with a right-skewed
-delay, a night-sleep window anchored to the opponent's timezone, and nudge
+win (≈ 40%), targets a small score margin, and times its moves with a move-number-aware
+right-skewed delay (quick openings, long endgames), a night-sleep window anchored to the opponent's timezone, and nudge
 behaviour — all derived deterministically from the game seed, so it keeps no extra
-state. The matchmaker now substitutes a pooled robot after a 10-second wait and
+state. The matchmaker now substitutes a pooled robot (matching the game's language) after a 10-second wait and
 exposes `Poll` so a waiting player can collect the started game (the live
 match-found notification arrives with the `gateway`).