feat(chat): backoffice list of the restrictions reaching a room

[okapitula]

Summary

Adds adminListRoomRestrictions (GET /backoffice/chat/rooms/{roomId}/restrictions): the active mutes, bans and cooldowns that reach one room, paginated and newest first, with who set each one. Stacks on #261 (base branch feat/chat-player-restrictions), which stacks on #260.

Why

The admin mute, ban and cooldown lists filter by user only. Without a filter they return every active row on the platform, unpaginated, and say neither who set an entry nor the player's username. Which wide scopes reach a room depends on the room kind (platformScopesFor(roomReach(room))), and room-moderator mutes and bans live in their own tables, so a consumer cannot build a per-room view from the existing routes without re-implementing core's reach rules. Every operator running the backoffice needs to see who is restricted in a room.

• One UNION ALL over chat_mute, chat_platform_ban, chat_player_cooldown, chat_room_mute and chat_room_ban, plus a count, paginated in SQL with id as the tiebreak. type filters to mute, ban or cooldown.
• Each item reports source (admin for staff rows, room for room-moderator rows), scope, roomId, reason (null for a room-moderator ban), setByName (the player username for room rows, the staff account name for admin rows, null if not found), cooldownSeconds (null unless a cooldown), createdAt and expiresAt.
• Guarded by chat-moderation:view, like the existing lists. An unknown or deleted room returns 404; the global room is addressed by its row id or __global.
• Partial indexes on (room_id, expires_at) and (scope, expires_at) where lifted_at IS NULL for the three admin tables, so expired history does not slow the listing.

Alternatives considered

• A roomId filter on the existing mute and ban lists: it would miss wide-scope rows that reach the room and the room-moderator tables.
• Reading through the CHAT_MODERATION port: the port has no per-room query, and adding one widens an overridable port. This reads core's tables directly, like the other admin room routes.

Risks

• An operator who rebinds CHAT_MODERATION to store mutes, bans or cooldowns elsewhere gets an incomplete list from this route.
• total and the page come from two queries, so a restriction set or lifted between them can make them disagree by one, as with the room list.
• Migration 0018_chat_restriction_room_indexes only adds indexes.

[zaxovaiko]

Looks good. One to check later: the restricted-players lookup does not filter isPublic, so an admin with chat-moderation view can list private room bans/mutes.