feat: Add Chat UX improvements with notifications and @mention support

- Add ActionBar component with expandable toolbar for mobile
- Add @mention functionality with autocomplete dropdown
- Add browser notification system (push, sound, vibration)
- Add NotificationSettings modal for user preferences
- Add mention badges on room list cards
- Add ReportPreview with Markdown rendering and copy/download
- Add message copy functionality with hover actions
- Add backend mentions field to messages with Alembic migration
- Add lots field to rooms, remove templates
- Optimize WebSocket database session handling
- Various UX polish (animations, accessibility)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

openspec/specs/realtime-messaging/spec.md

@@ -192,3 +192,148 @@ The system SHALL support message editing and deletion with proper audit trail an
 - **AND** broadcast to all connected clients
 - **AND** aggregate reaction counts for display
 
+### Requirement: Short-lived Database Sessions for WebSocket
+The system SHALL process WebSocket messages using short-lived database sessions that are acquired and released for each individual operation, rather than holding a session for the entire WebSocket connection lifetime.
+
+#### Scenario: Message creation with short session
+- **WHEN** a user sends a message via WebSocket
+- **THEN** the system acquires a database session
+- **AND** creates the message with proper sequence number
+- **AND** commits the transaction
+- **AND** releases the session immediately
+- **AND** broadcasts the message to room members
+
+#### Scenario: Concurrent message handling
+- **WHEN** multiple users send messages simultaneously
+- **THEN** each message operation uses an independent database session
+- **AND** sequence numbers are correctly assigned without duplicates
+- **AND** no connection pool exhaustion occurs
+
+### Requirement: Message Sequence Number Integrity
+The system SHALL guarantee unique, monotonically increasing sequence numbers per room using database-level locking to prevent race conditions during concurrent message creation.
+
+#### Scenario: Concurrent sequence assignment
+- **WHEN** two users send messages to the same room at the exact same time
+- **THEN** each message receives a unique sequence number
+- **AND** the sequence numbers are consecutive without gaps or duplicates
+
+#### Scenario: High concurrency sequence safety
+- **WHEN** 50+ users send messages to the same room simultaneously
+- **THEN** all messages receive correct unique sequence numbers
+- **AND** the operation does not cause deadlocks
+
+### Requirement: Configurable Database Connection Pool
+The system SHALL support environment variable configuration for database connection pool parameters to optimize for different deployment scales.
+
+#### Scenario: Custom pool size configuration
+- **WHEN** the application starts with `DB_POOL_SIZE=20` environment variable
+- **THEN** the connection pool maintains 20 persistent connections
+
+#### Scenario: Pool overflow configuration
+- **WHEN** the application starts with `DB_MAX_OVERFLOW=30` environment variable
+- **THEN** the connection pool can expand up to 30 additional connections beyond the pool size
+
+#### Scenario: Pool timeout configuration
+- **WHEN** all connections are in use and a new request arrives
+- **AND** `DB_POOL_TIMEOUT=10` is configured
+- **THEN** the request waits up to 10 seconds for an available connection
+- **AND** raises an error if no connection becomes available
+
+#### Scenario: Default configuration
+- **WHEN** no database pool environment variables are set
+- **THEN** the system uses production-ready defaults (pool_size=20, max_overflow=30, timeout=10, recycle=1800)
+
+### Requirement: Message Sender Display Name
+
+The system SHALL include the sender's display name in message responses and broadcasts, enabling the UI to show user-friendly names instead of email addresses.
+
+#### Scenario: Message response includes display name
+- **WHEN** a message is retrieved via REST API or WebSocket
+- **THEN** the response SHALL include `sender_display_name` field
+- **AND** the display name SHALL be obtained by joining with the `tr_users` table
+- **AND** if the sender does not exist in `tr_users`, the field SHALL fallback to `sender_id`
+
+#### Scenario: WebSocket broadcast includes display name
+- **WHEN** a new message is broadcast via WebSocket
+- **THEN** the broadcast SHALL include `sender_display_name` field
+- **AND** the value SHALL be the sender's display name from `tr_users` table
+
+#### Scenario: Historical messages include display name
+- **WHEN** a client requests message history via `GET /api/rooms/{room_id}/messages`
+- **THEN** each message in the response SHALL include `sender_display_name`
+- **AND** messages from unknown users SHALL show their `sender_id` as fallback
+
+### Requirement: GMT+8 Timezone Display
+
+The frontend SHALL display all timestamps in GMT+8 (Asia/Taipei) timezone for consistent user experience across all browsers.
+
+#### Scenario: Message timestamp in GMT+8
+- **WHEN** a message is displayed in the chat room
+- **THEN** the timestamp SHALL be formatted in GMT+8 timezone
+- **AND** use format "HH:mm" for today's messages
+- **AND** use format "MM/DD HH:mm" for older messages
+
+#### Scenario: Room list timestamps in GMT+8
+- **WHEN** the room list is displayed
+- **THEN** the "last updated" time SHALL be formatted in GMT+8 timezone
+
+### Requirement: @Mention Support
+The messaging system SHALL support @mention functionality to tag specific users in messages.
+
+#### Scenario: Trigger mention autocomplete
+- **WHEN** user types `@` in the message input
+- **THEN** a dropdown menu appears showing room members
+- **AND** the list filters as user continues typing
+- **AND** user can select a member using keyboard or mouse
+
+#### Scenario: Insert mention into message
+- **WHEN** user selects a member from the mention dropdown
+- **THEN** the mention is inserted as `@display_name`
+- **AND** the mention is stored with the user_id reference
+- **AND** the mention is visually highlighted in the message
+
+#### Scenario: Mention notification
+- **WHEN** a message containing @mention is sent
+- **THEN** the mentioned user receives a highlighted notification
+- **AND** the notification indicates they were mentioned
+
+### Requirement: Browser Push Notifications
+The system SHALL support browser push notifications for new messages.
+
+#### Scenario: Request notification permission
+- **WHEN** user first visits the chat room
+- **THEN** the system prompts for notification permission
+- **AND** the permission state is stored locally
+
+#### Scenario: Send push notification
+- **WHEN** a new message arrives while the tab is not focused
+- **AND** user has granted notification permission
+- **THEN** a browser push notification is displayed
+- **AND** clicking the notification focuses the chat room
+
+### Requirement: Sound and Vibration Alerts
+The system SHALL support audio and haptic feedback for new messages.
+
+#### Scenario: Play notification sound
+- **WHEN** a new message arrives
+- **AND** sound notifications are enabled
+- **THEN** a notification sound is played
+
+#### Scenario: Vibrate on mobile
+- **WHEN** a new message arrives on a mobile device
+- **AND** vibration is enabled
+- **AND** the device supports Vibration API
+- **THEN** the device vibrates briefly
+
+### Requirement: Mention Data Storage
+Messages with @mentions SHALL store the mention metadata for querying.
+
+#### Scenario: Store mention references
+- **WHEN** a message with @mentions is created
+- **THEN** the `mentions` field stores an array of mentioned user_ids
+- **AND** the message content preserves the @display_name format
+
+#### Scenario: Query messages mentioning user
+- **WHEN** fetching messages that mention a specific user
+- **THEN** messages with that user_id in `mentions` array are returned
+