feat: signal server tag

agents-docs/FEATURES.md

@@ -10,6 +10,7 @@ It must stay accurate as new features are introduced, renamed, merged, or remove
 
 - [Custom Emoji](features/custom-emoji.md) — peer-synced user-created emoji assets, chat reaction shortcuts, and composer emoji insertion.
 - [Server Discovery](features/server-discovery.md) — featured/trending public-server REST endpoints (server) consumed by the `/dashboard` and `/servers` client pages.
+- [Signal Server Tag](features/signal-server-tag.md) — configurable signal-server display tag shown on profile cards for a user's registration server.
 
 The product client already documents its bounded contexts at `toju-app/src/app/domains/<name>/README.md` (Access Control, Attachment, Authentication, Chat, Direct Call, Direct Message, Experimental Media, Game Activity, Notifications, Plugins, Profile Avatar, Screen Share, Server Directory, Theme, Voice Connection, Voice Session). Those domain READMEs cover internal product-client behavior.
 

agents-docs/LESSONS.md

@@ -25,6 +25,20 @@ Durable rules for AI agents working on this project. Read this file at session s
 
 ## Lessons
 
+### Use the upgrade transaction during IndexedDB schema migrations [persistence] [browser]
+
+- **Trigger:** bumping `BROWSER_DATABASE_VERSION` and opening existing stores via `database.transaction(...)` inside `onupgradeneeded`.
+- **Rule:** during `onupgradeneeded`, reuse `event.transaction.objectStore(name)` for existing stores and only call `database.createObjectStore` for missing ones — never start a second transaction while the version-change transaction is active.
+- **Why:** nested transactions abort the upgrade, `authenticateUser` storage prep fails, and login/register navigates before `setCurrentUser` so DM routes throw "Cannot use direct messages without a current user."
+- **Example:** `ensureObjectStoreDuringUpgrade(database, upgradeTransaction, 'messages')` in `browser-database-schema.ts`.
+
+### Wait for authenticateUser storage prep before post-login navigation [authentication] [browser]
+
+- **Trigger:** dispatching `UsersActions.authenticateUser` from login/register and immediately calling `router.navigate(...)`.
+- **Rule:** wait for `setCurrentUser` or `loadCurrentUserFailure` (e.g. `waitForAuthenticationOutcome(actions$)`) before navigating to `returnUrl` or `/dashboard`.
+- **Why:** `authenticateUser$` prepares per-user IndexedDB asynchronously; early navigation renders DM/shell routes before the current user exists in the store.
+- **Example:** `await firstValueFrom(waitForAuthenticationOutcome(this.actions$))` in `register.component.ts` and `login.component.ts`.
+
 ### Use dense arrays for chunked transfer buffers [custom-emoji] [webrtc]
 
 - **Trigger:** chunked P2P asset assembly marks a transfer complete after the first chunk because `array.some()` skips sparse holes created by `new Array(total)`.

agents-docs/features/signal-server-tag.md

@@ -0,0 +1,22 @@
+# Signal Server Tag
+
+Users registered on a signal server can show that server's display tag on their profile card (opened by clicking their name or avatar).
+
+## Server configuration
+
+`server/data/variables.json` accepts an optional `serverTag` string. When omitted, the server falls back to its public URL built from `serverProtocol`, `serverHost`, and `serverPort`.
+
+## Health API
+
+`GET /api/health` includes `serverTag` so clients can cache the display label per configured endpoint.
+
+## WebSocket presence
+
+The client sends `homeSignalServerUrl` in `identify` messages. The signaling server echoes that value in `server_users` and `user_joined` payloads so other clients can resolve the correct tag.
+
+## Client behavior
+
+- Login and registration store `homeSignalServerUrl` on the current user.
+- Profile cards show the resolved tag beside the username in muted text.
+- Configured labels render as `#tag`; URL fallbacks render as a globe icon with the URL in a tooltip.
+- Tag resolution prefers the endpoint's cached `serverTag` from health checks, then falls back to the stored home URL.