fix: Bug - No login screen mobile phone on startup

Signed-out mobile visitors landing on / or /dashboard were intentionally
kept on a logged-out /dashboard, so they were never greeted with a login
screen on startup. Replace the imperative startup-redirect logic in
App.ngOnInit with a platform-agnostic pure rule
resolveUnauthenticatedStartupRedirect: non-public routes redirect to
/login (with a safe returnUrl), public routes (/login, /register,
/invite/...) are left alone. Mobile is no longer special-cased.

- Unit: auth-navigation.rules.spec.ts
- E2E: e2e/tests/mobile/mobile-login-on-startup.spec.ts (mobile viewport
  set before navigation; /dashboard and / both land on /login)

Co-authored-by: Cursor <cursoragent@cursor.com>

agents-docs/LESSONS.md

@@ -25,6 +25,13 @@ Durable rules for AI agents working on this project. Read this file at session s
 
 ## Lessons
 
+### Don't strand signed-out mobile users on a logged-out dashboard [auth] [mobile] [routing]
+
+- **Trigger:** `App.ngOnInit` special-cased mobile — signed-out visitors landing on `/` or `/dashboard` were kept on `/dashboard` (the "login form has no mobile chrome" rationale), so mobile users got a logged-out dashboard and never saw a login screen on startup.
+- **Rule:** decide startup routing for signed-out users with the platform-agnostic pure rule `resolveUnauthenticatedStartupRedirect(currentUrl)` (`auth-navigation.rules.ts`) — non-public routes → `/login` (with safe `returnUrl`), public routes (`/login`, `/register`, `/invite/...`) → stay; do not branch on `isMobile()` here.
+- **Why:** the mobile exception directly contradicted the product expectation ("greet signed-out users with the login screen"); the login form already links to register, so there is no dead-end to avoid.
+- **Example:** unit `auth-navigation.rules.spec.ts` (`resolveUnauthenticatedStartupRedirect('/dashboard') === { path:'/login', queryParams:{} }`); e2e `e2e/tests/mobile/mobile-login-on-startup.spec.ts` sets a 390×844 viewport **before** navigating (so `ViewportService.isMobile` is true at bootstrap) and asserts `/dashboard` and `/` both land on `/login`.
+
 ### "Shared from your device" must gate on local bytes, not uploader user id [attachments] [multi-device]
 
 - **Trigger:** a second device of the same user showed "Shared from your device" and hid the download affordance for a file uploaded from another device — `isUploader(attachment)` returned `uploaderPeerId === currentUserId`, but `uploaderPeerId` is the **user** id (set to `currentUser.id` in `publishAttachments`), so it is true on every device of the uploader, including ones that only synced metadata.

agents-docs/features/authentication.md

@@ -118,6 +118,8 @@ Authorize UI: `/login?mode=authorize&serverId=…&returnUrl=…` (also supported
 
 Persisted local user state (`metoyou_currentUserId` + IndexedDB/SQLite profile) is **not** sufficient to use chat or presence. On startup, `loadCurrentUser$` requires a non-expired session token for the user's home signaling server (or any stored token as a fallback). Missing or rejected **home** tokens dispatch `SESSION_EXPIRED` and redirect to `/login`. Foreign-server `auth_required` / `auth_error` responses clear only that server's credential and attempt re-provision.
 
+Startup routing for signed-out visitors is decided by `resolveUnauthenticatedStartupRedirect(currentUrl)` (`auth-navigation.rules.ts`), called from `App.ngOnInit`: any non-public route is redirected to `/login` (carrying a safe `returnUrl`), while public routes (`/login`, `/register`, `/invite/...`) are left alone. This is **platform-agnostic** — mobile is intentionally not special-cased, so a signed-out mobile user is greeted with the login screen on startup rather than a logged-out `/dashboard`.
+
 ## Security considerations
 
 - Rate limits: login/register (100 / 15 min), server join (30 / min).