Phase 28 (Step 10): docs — diplomail UI topic + FUNCTIONAL mirror

- `ui/docs/diplomail-ui.md`: new topic doc covering the wire
  surface, recipient-by-race-name decision, threading model,
  translation toggle, push events, badge, layout, and
  accessibility.
- `docs/FUNCTIONAL.md` §11.4 grows a paragraph that records the
  UI's per-race threading rule, the absent read-receipt UX, and
  the recipient-by-race-name compose path. Mirrored verbatim into
  `docs/FUNCTIONAL_ru.md`.
- `ui/PLAN.md` Phase 28 marked done with a "Decisions during
  stage" block matching the implementation plan, and the artifact
  list updated to the actual file set.

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

docs/FUNCTIONAL.md

@@ -1270,6 +1270,20 @@ The message detail response includes both the original body and,
 when available, the cached translation; the client UI defaults to
 the translated text and offers a "show original" toggle.
 
+The in-game UI groups personal mail into per-race threads — every
+personal message exchanged between the local player and another
+race lands in one thread keyed on the other party's race. System
+mail, admin notifications, and the player's own paid-tier
+broadcasts render as stand-alone entries in the same list pane and
+are never threaded. `read_at` and `deleted_at` drive the local
+unread counter and the soft-delete affordance but are not surfaced
+to the user — diplomatic mail does not promise read receipts. The
+compose form picks the recipient by race name (resolved
+server-side from `Memberships.ListMembers(game_id, "active")`); no
+client-side memberships listing is fetched. See
+[`ui/docs/diplomail-ui.md`](../ui/docs/diplomail-ui.md) for the
+detailed UI breakdown.
+
 ### 11.5 Lifecycle hooks
 
 Three lobby transitions land as system mail in the affected