fix(social): robot blocks

Blocking an auto-match opponent who is secretly a pooled robot is recorded  instead in a separate `robot_blocks` table.

Now blocking behaves the same in that game (struck name, hidden composer) and lists the blocked opponent under the name you saw, but is recorded only against that game — the disguise holds, the shared robot is never globally blocked, and the matchmaker keeps pairing you with robots (so you can never block yourself out of opponents).

- the shared robot account is never put in `blocks`
- the matchmaker keeps it free and it is not blocked under its other per-game names
- the blocked list and the in-game card still show it by joining that table; an unblock deletes the row

docs/ARCHITECTURE.md

@@ -520,7 +520,12 @@ in either direction (the enqueue excludes the caller's `BlockedWith` set);
   **overrides but does not delete** a friendship (an unblock cleanly restores it), so a pair may
   be friends **and** blocked at once; the admin user card shows the full truth (blocks,
   blocked-by, friends) regardless of this suppression. Block/unblock emit a `user_blocked` /
-  `user_unblocked` notification to the blocker only (§10).
+  `user_unblocked` notification to the blocker only (§10). Blocking an auto-match opponent who
+  is secretly a pooled robot is recorded instead in a separate **`robot_blocks`** table, keyed on
+  the blocker + game + seat with the seen name snapshotted (`BlockInGame`): the shared robot
+  account is never put in `blocks` (so the matchmaker keeps it free and it is not blocked under
+  its other per-game names), while the blocked list and the in-game card still show it by joining
+  that table; an unblock deletes the row.
 - **Friend games**: formed by **invitation → accept** (an `game_invitations`
   record with one row per invitee). The 2–4 player game starts once **every**
   invitee accepts; any decline cancels the invitation, and a pending invitation