fix: Fix multiple bugs with new authentication flow

agents-docs/LESSONS.md

@@ -25,6 +25,20 @@ Durable rules for AI agents working on this project. Read this file at session s
 
 ## Lessons
 
+### Revalidate IndexedDB scope without reinitializing on every read [persistence] [performance]
+
+- **Trigger:** `DatabaseService.ensureReady()` called `initialize()` before every delegated read/write to fix user-scope races.
+- **Rule:** cache the last validated `metoyou_currentUserId` and only re-run backend initialization when that scope changes or an in-flight initialize completes with a different scope.
+- **Why:** per-operation revalidation fans out across ban lookups, room loads, and message reads, causing channel/chat UI to stay blank until repeated server clicks eventually win the race.
+- **Example:** `ensureReady()` returns immediately when `isReady()` and `validatedUserScope` still match `getStoredCurrentUserId()`.
+
+### Restore local user scope before protected writes [authentication] [persistence]
+
+- **Trigger:** a logged-in in-memory user can create rooms or messages after `metoyou_currentUserId` was cleared by a late session-expired path.
+- **Rule:** before protected local persistence or server-directory actions, restore `metoyou_currentUserId` from the current user and avoid treating a live current user as unauthenticated.
+- **Why:** otherwise rooms/messages fall into the anonymous IndexedDB scope, and route checks redirect to login even though NgRx still has the authenticated user.
+- **Example:** `MessagesEffects.sendMessage$`, `RoomsEffects.createRoom$`, and server-directory create/join components call `setStoredCurrentUserId(currentUser.id)` before writing or joining.
+
 ### Persisted local user state still requires a session token [authentication] [signaling]
 
 - **Trigger:** Users appear logged in from local storage but cannot see peers online or send chat after session-token auth shipped.

agents-docs/adr/0003-multi-client-sessions.md

@@ -0,0 +1,16 @@
+# ADR-0003: Multi-Client Sessions with Connection-Scoped Routing
+
+## Status
+Accepted
+
+## Context
+Users expect to stay logged in on multiple devices simultaneously (Discord-style). The signaling server already issued multiple session tokens per user, but WebSocket broadcasts deduplicated by `oderId`, which prevented a user's second device from receiving chat, typing, or voice-state updates from their first device. Voice had no per-device identity, so two clients could both attempt to transmit audio.
+
+## Decision
+Introduce a stable per-install `clientInstanceId` on the product client. Route server broadcasts by **connection id** (exclude only the sender socket) while keeping presence `user_joined` / `user_left` identity-scoped. Track `voiceActive` per connection; relay RTC to the voice-active socket. Enforce single voice owner per user via `VoiceState.clientInstanceId` and `voice_client_takeover` handoff between connections.
+
+## Consequences
+- **Positive:** Chat and presence sync across a user's devices; voice behaves like Discord (one transmitting client, passive viewers, explicit takeover).
+- **Positive:** Stale-tab hygiene uses `(oderId, connectionScope, clientInstanceId)` eviction without kicking other devices.
+- **Negative:** `findUserByOderId` semantics change — RTC now prefers voice-active connections; callers must not assume one socket per user.
+- **Negative:** Clients must include `clientInstanceId` on identify and voice payloads; older builds without it still work but cannot participate in multi-device voice exclusivity reliably.

agents-docs/features/authentication.md

@@ -25,7 +25,7 @@ Session-token authentication for the signaling server and product client.
 ```
 
 - Tokens are opaque 64-character hex strings stored in server SQLite (`session_tokens`).
-- Default TTL: 24 hours (`SESSION_TOKEN_TTL_MS` env override supported).
+- Default TTL: 10 years (`SESSION_TOKEN_TTL_MS` env override supported on the signaling server).
 - Passwords are stored with bcrypt; legacy SHA-256 hashes are upgraded transparently on successful login.
 
 ## Protected REST routes
@@ -46,13 +46,22 @@ Require `Authorization: Bearer`:
   "token": "<session-token>",
   "oderId": "<user-id>",
   "displayName": "Alice",
-  "connectionScope": "ws://host:3001"
+  "connectionScope": "ws://host:3001",
+  "clientInstanceId": "<per-install-uuid>"
 }
 ```
 
 - `oderId` must match the token's user id when provided.
+- `clientInstanceId` is a stable per-install UUID generated by the product client (`metoyou.clientInstanceId` in `localStorage`). The signaling server uses it to distinguish multiple WebSocket connections for the same user and to route voice ownership.
 - Server responds with `auth_error` or `auth_required` when authentication fails.
 
+## Multi-device sessions
+
+- Each login/register issues a **new** session token; prior tokens remain valid until they expire or the client calls `POST /api/users/logout` with that token.
+- The same user may keep multiple WebSocket connections open (different devices or browser profiles). Server broadcasts (chat, typing, voice state, status) exclude only the **sending connection**, so other connections for that identity still receive updates.
+- Voice/WebRTC is exclusive per user: only one `clientInstanceId` may own active voice at a time. Other connections show passive UI and can send `voice_client_takeover` to move voice to the local device.
+- Stale reconnect hygiene: when a client re-identifies with the same `(oderId, connectionScope, clientInstanceId)` tuple, the server closes the older socket for that tuple.
+
 ## Client storage
 
 The product client stores tokens per signaling-server base URL in `localStorage` (`metoyou.authTokens`). An HTTP interceptor attaches the bearer token to `/api/*` requests targeting that server.