feat(dashboard): add hardened API-only remote proxy

[joelbrilliant]

Problem

The desktop remote gateway expects a trusted proxy, but tunnelling the whole dashboard server exposes more of the host than remote Desktop access needs.

1. The SPA HTML embeds the dashboard session token.
2. Machine lifecycle routes can update, restart, back up, import, or migrate the local Hermes installation.
3. Denied probes have no durable attribution without a dedicated audit log.

Related remote access demand appears in #9269, #8951, #34390, #37119, #39553, and #53839.

Security model

This is an API-only topology for Desktop token authentication. The loopback backend remains the authentication authority for every protected HTTP and WebSocket route. Configure a fixed HERMES_DASHBOARD_SESSION_TOKEN on the backend and enter the same value in Desktop token mode.

The proxy does not forward /login, /auth/callback, the SPA, or static assets. Browser OAuth and the browser dashboard are intentionally unsupported through this surface. Use the normal authenticated non-loopback dashboard deployment when those are required.

What this adds

• A hermes dashboard proxy command that forwards only /api/* HTTP and WebSocket traffic to the loopback backend.
• Default denials for machine lifecycle, backup, import, migration, and gateway control routes.
• Explicit route policy overrides for operators who need a different boundary.
• HTTP and WebSocket denial auditing in logs/remote-proxy-denied.log.
• Repeated response header preservation, including multiple Set-Cookie fields.
• Hop-by-hop header stripping in both directions.
• Documentation for fixed-token Desktop setup through Cloudflare, Tailscale, or SSH tunnelling.
• No new dependencies.

Review follow-up

The hermes-sweeper findings are addressed in the follow-up commit:

• The supported token topology is explicit and the incorrect OAuth claims are removed.
• Browser authentication bootstrap routes remain closed by design.
• Repeated upstream response headers are preserved.
• Denied WebSocket upgrades are audited.
• A production-shaped regression runs the proxy against the real loopback backend and proves missing tokens receive 401 while the correct token succeeds.
• Existing dashboard parser test harnesses now receive the proxy handler, fixing the seven Python CI failures on the original commit.

Validation

• scripts/run_tests.sh across the proxy, HTTP auth, WebSocket auth, admin endpoint, dashboard parser, and serve parser suites
• 205 tests passed
• Ruff passed for every changed Python file
• git diff --check passed
• Documentation shell examples passed syntax validation

[teknium1]

Thanks for addressing a real remote-dashboard boundary problem; the API-only and lifecycle-deny direction is useful. There are blocking integration issues.

Problems

• hermes_cli/remote_proxy.py:118 returns 404 for every non-/api path. Desktop OAuth intentionally opens /login (apps/desktop/electron/main.ts:5119-5121, 5255) and completes through /auth/callback, so the documented sign-in flow cannot work through this proxy.
• The documented loopback hermes serve topology does not engage the current OAuth gate: loopback is explicitly a no-op in hermes_cli/dashboard_auth/middleware.py:13-15, while start_server() derives auth_required from the bind host (hermes_cli/web_server.py:17856-17879).
• hermes_cli/remote_proxy.py:206 collapses response headers into a dict. Dashboard auth emits multiple Set-Cookie headers (hermes_cli/dashboard_auth/cookies.py:191-212), so cookie-based auth cannot be forwarded reliably.

Suggested changes

• Design an explicit authenticated loopback-upstream mode, then allow only the narrow auth-bootstrap routes needed by Desktop—without serving the SPA/static surface.
• Preserve repeated response headers and add an end-to-end OAuth/login + WS-ticket proxy test.
• Audit denied WebSocket upgrades as well as HTTP denies.

This is an automated hermes-sweeper review.

[joelbrilliant]

Thanks for the review. I rechecked the runtime auth path and found an important distinction: loopback disables the OAuth and password gate, but hermes_cli.web_server.auth_middleware still requires the dashboard session token on protected HTTP routes, and the WebSocket path requires the same token. Desktop token mode already sends X-Hermes-Session-Token for HTTP and ?token= for WebSockets.

Addressed in the pushed commits:

• Made fixed-token Desktop mode the explicit supported topology. /login and /auth/callback remain 404 by design, and the docs no longer claim browser OAuth or the browser dashboard work through this API-only surface.
• Preserved repeated upstream response headers through raw_headers, including multiple Set-Cookie fields.
• Added audit entries for denied WebSocket upgrades.
• Added a production-shaped regression that runs the proxy against the real loopback backend. A missing token receives 401 and the correct token succeeds on a protected route.
• Wired the proxy handler into the existing dashboard parser test harnesses, fixing all seven Python CI failures from the original commit.

Verified after rebasing onto current main: 205 tests passed across the proxy, HTTP auth, WebSocket auth, admin endpoint, dashboard parser, and serve parser suites. Ruff and git diff --check also pass.

Out of scope for this PR: supporting browser OAuth or the browser dashboard through the API-only proxy. That needs a separate auth-bootstrap design rather than partially exposing login routes here.