[BUG]: Self-deadlock in handleRoleSelection hangs the WebSocket connection on every role pick

### Bug Description

`handleRoleSelection` in `backend/websocket/websocket.go` locks `room.Mutex` (lines 668–669) and keeps it locked until the function returns using `defer`. While the lock is still held, it calls `snapshotRecipients` (line 678) and `broadcastParticipants` (line 684). Both of these helpers try to acquire the same `room.Mutex` again (lines 108–110 and 191).

Since `sync.Mutex` isn't reentrant, the second `Lock()` call blocks forever, resulting in a deadlock.

### Impact

As soon as a user selects a role in an online debate room, the goroutine handling that WebSocket connection gets stuck. Because the mutex is never released, other operations that need the same room lock can also end up blocked.

### Suggested Fix

Unlock `room.Mutex` before calling `snapshotRecipients` and `broadcastParticipants`, or refactor those helpers to work with an already-locked room (for example, by introducing `snapshotRecipientsLocked`).

### Steps to Reproduce

1. Open an online debate room with two users.
2. Select a role (For/Against).
3. The client stops receiving WebSocket messages, and the backend goroutine deadlocks (can be confirmed with a `SIGQUIT` goroutine dump).

### Logs and Screenshots

_No response_

### Environment Details

_No response_

### Impact

High - Major feature is broken

### Code of Conduct

- [x] I have joined the [Discord server](https://discord.gg/hjUhu33uAn) and will post updates there
- [x] I have searched existing issues to avoid duplicates

Start in backend/websocket/websocket.go at handleRoleSelection and trace the calls to snapshotRecipients and broadcastParticipants named in the issue. Reproduce role selection with two users and use a SIGQUIT goroutine dump if needed. Done means selecting a role no longer deadlocks and the client continues receiving WebSocket messages.

Written by the indexing model from the issue text.