Stage 17 round 6 (#16/#17, PR C): lobby sort + server-derived in-game friend state

Lobby: group the my-games list into your-turn / opponent-turn / finished (empty sections hidden), ordered by last activity (your-turn oldest-first, the other two newest-first), as a compact line-separated list. gameDTO and FB GameView gain last_activity_unix (turn start while active, finish time once finished); a pure lib/lobbysort.ts holds the grouping/ordering. Friends: the in-game 'add to friends' item is now server-derived via a new GET /user/friends/outgoing (+ friends.outgoing op), returning addressees with a pending OR declined request (both read as 'request sent'), so it is correct across reloads; it shows a disabled '✓ in friends' once accepted. It live-updates when the opponent answers: RespondFriendRequest now publishes friend_added (accept) / friend_declined (new notify sub-kind, decline) to the original requester, whose open game re-derives its friend state. Tests: lobbysort unit test; gateway outgoing + last_activity transcode tests; backend integration ListOutgoingRequests + respond-publishes-to-requester; e2e updated for the new lobby section labels + a non-friend active opponent. Docs: ARCHITECTURE notify catalog, FUNCTIONAL(+ru) lobby/friends, PLAN.
2026-06-08 19:23:48 +02:00
parent b720907db2
commit 6b6baf5710
40 changed files with 743 additions and 81 deletions
@@ -473,8 +473,10 @@ including the mover**, so the mover's own other devices and their lobby refresh
 in-app only, so the actor gets no out-of-app push for their own move), **chat-message** and **nudge**
 (from the social service), **match-found** (from the matchmaker, §8), and **notify**
 (Stage 8 — a lightweight "re-poll" signal carrying a sub-kind: friend-request,
-friend-added, invitation or game-started; emitted on a friend-request and invitation
-create and on an invitation's game start). Event payloads are FlatBuffers-encoded by
+friend-added, friend-declined, invitation or game-started; emitted on a friend-request,
+on answering one (accept → friend-added, decline → friend-declined — to the original
+requester, so a game screen watching that opponent re-derives its "add to friends" state,
+Stage 17), and on an invitation create or its game start). Event payloads are FlatBuffers-encoded by
 the backend and forwarded verbatim. A client that is not currently streaming falls
 back to the matchmaker's `Poll` for match-found and, for the lobby **notification
 badge** (incoming friend requests + open invitations), the client polls on lobby