feat(desktop): add secure Continue on phone

[joelbrilliant]

Summary

Adds a secure, persistent Continue on phone flow to Hermes Desktop.

Users can open it from:

• the phone button beside the active chat composer
• the session actions menu
• /remote-control or /rc

Desktop displays a one-time QR code valid for 120 seconds. The phone exchanges it for a persistent, revocable linked-device credential and opens the exact selected chat. Future visits reconnect silently until the device is revoked, browser data is cleared, or the 90-day inactivity window expires.

Linked devices appear in Desktop settings with their device name, linked date, last-used date and a Revoke action.

Phone permission boundary

A linked phone can:

• view and continue the linked chat
• reconnect to that chat without signing in again

It cannot access:

• plugins or plugin navigation
• credentials or environment configuration
• administrative settings
• session browsing or unrelated sessions
• standalone terminal, model or tool configuration controls

An ended session asks the user to link it again rather than creating a new session from the phone.

Security boundary

• The bootstrap ticket is single-use and expires after 120 seconds.
• The ticket remains in the URL fragment and is not sent in the HTTP request line or Referer.
• Cross-process tickets are stored using their SHA-256 hash and consumed with an atomic delete.
• The persistent device secret is stored only in an HttpOnly, Secure, SameSite=Lax browser cookie.
• Hermes stores only the credential hash on the Mac.
• Linked credentials receive exact resume-only scope bound to one session and profile.
• Revocation invalidates subsequent HTTP and WebSocket access.
• The Hermes Desktop backend remains loopback-only and does not accept the configured public Host header.
• Resume-only clients receive the chat interface without dashboard navigation, plugins or administrative surfaces.

Scope

This PR does not add:

• a managed relay or tunnel
• a native mobile app
• push notifications
• PWA installation support, which remains in feat(web): add installable mobile dashboard PWA #77086
• the mobile soft-keyboard fix, which remains in fix(web): keep chat terminal input line above the mobile soft keyboard (NS-434) #74579

It requires an operator-configured HTTPS dashboard public URL with the existing browser authentication gate enabled.

This supersedes the earlier Desktop-only QR implementation in #67668.

Verification

• GitHub required-check gate passes at afaa7e67d
• Full Desktop UI suite: 3,325 tests passed
• Focused dashboard authentication and handoff suite: 112 tests passed
• Desktop typecheck, lint and production build passed
• Web tests, typecheck, lint and production build passed
• Physical iPhone Safari testing confirmed QR pairing, chat continuation, message entry and persistent reconnection
• Replay, expiry, hostile path, foreign session, scope tampering and revocation cases fail closed

[teknium1]

Thanks for the thorough ticket, scope, and WS binding work. Two issues need resolution before this can safely support the documented deployment path.

Problems

• The new loopback tunnel/reverse-proxy instructions (website/docs/user-guide/features/web-dashboard.md:921-945) cannot engage the gate: current should_require_auth() returns False for loopback binds (hermes_cli/web_server.py:442-461), and start_server() assigns that result to app.state.auth_required (hermes_cli/web_server.py:17064). Thus the documented public origin remains token-mode, contrary to the feature's gated-SPA requirement.
• isPhoneHandoffAuthMode() accepts "handoff" (apps/desktop/src/lib/continue-on-phone.ts:31-35), but the actual probe type only allows oauth | token | unknown (apps/desktop/src/global.d.ts:588-595) and probeRemoteAuthMode() only returns oauth or token (apps/desktop/electron/main.ts:7612-7645). The new test covers a value production cannot produce.

Suggested changes

• Implement and integration-test a real public-proxy gate activation path, or remove/reject the loopback-tunnel deployment guidance.
• Align the handoff-mode predicate with the real probe contract, or extend that contract end-to-end.

Automated hermes-sweeper review.

[joelbrilliant]

Rebased this onto current main (6ecd335) and refreshed the branch at df132dccf.\n\nCurrent proof:\n\n- 199 focused backend auth, handoff, runtime and browser tests\n- 19 focused Desktop handoff tests\n- full Desktop gate: 3,179 UI tests, 899 platform tests, typecheck, lint, app build and macOS DMG build\n- full web gate: 144 tests, typecheck, lint and production build\n- phone viewport check at 393 x 852 with no horizontal overflow\n\nThe security model is unchanged: a single-use 120-second handoff ticket, a 45-minute resume-scoped cookie, the ticket stripped on consume, session/profile/channel-bound REST and WebSocket access, and default-deny everywhere else.\n\nHosted CI is now fully green: 40 successful checks, 0 failing and 0 pending. The PR is mergeable and ready for maintainer review.

[joelbrilliant]

Rebased onto current main and refreshed the branch at e33becb25.

The key hardening in this update is that the one-time handoff ticket no longer appears in the HTTP request URL. Desktop now emits /handoff#ticket=.... A nonce-protected same-origin bootstrap removes the fragment from browser history, exchanges it in a JSON POST body, sets the existing resume-scoped cookie, and opens the server-bound session.

Current proof:

• 223 focused backend auth, handoff, runtime, and browser tests
• 14 focused Desktop Continue-on-phone UI tests
• Desktop typecheck, lint, and production build
• Web typecheck, 144 tests, lint, and production build
• Real Chromium at an emulated iPhone 12 viewport, including exact-session landing and scoped WebSocket continuation

The PR body now records the overlap and remaining boundary. A physical iOS Safari and Android Chrome scan through a real HTTPS route is still the final device check.