feat(web): HERMES_SESSION_TOKEN env override for reverse-proxied deployments

[kingsleydon]

Summary

Lets operators pin the web-server's session token to a stable value via
the HERMES_SESSION_TOKEN env var, so reverse-proxied deployments where
the UI lives on a different origin can authenticate against /api/* without
scraping the HTML injection.

Why

_SESSION_TOKEN is currently secrets.token_urlsafe(32) — random at process
start, dies with the process, only surfaced via the window.__HERMES_SESSION_TOKEN__
script tag baked into the SPA HTML.

This is elegant for the single-user hermes web flow: one process serves the
SPA and the API, same origin, so the browser naturally picks up the token from
HTML on first load and uses it for all /api/* calls.

It breaks for reverse-proxied deployments (Clawdi is our motivating case —
one dashboard at app.clawdi.ai talking to many per-pod Hermes instances at
{app_id}-18793.{gateway}.phala.network). The dashboard is a separate Next.js
app on a different origin — it never loads the Hermes SPA HTML, so
window.__HERMES_SESSION_TOKEN__ is never set on its side, and it has no way
to learn the ephemeral token the Python process generated.

Teknium's auth_middleware (added 2026-04-14) correctly gates /api/*
behind this token, which is great for security, but completes the mismatch:
the dashboard can prove it's an authenticated Clawdi user (via its own JWT
flow), but it cannot authenticate to hermes-web.

Design

One-line change with a fallback:

_SESSION_TOKEN = os.environ.get("HERMES_SESSION_TOKEN") or secrets.token_urlsafe(32)

• Single-user hermes web: env var unset → fall back to random token →
  zero behaviour change. Comment block explains both flows so future readers
  know why the fallback exists.
• Reverse-proxied deployments: operator sets HERMES_SESSION_TOKEN to a
  stable value (on Clawdi we derive it alongside API_SERVER_KEY from the
  same per-pod MASTER_KEY via HKDF, so hermes-agent and hermes-web share
  one token without needing to coordinate).

Docstring updated to explain both code paths and when each applies.

Test plan

• Unset env var → hermes web single-user flow unaffected (token still random)
• HERMES_SESSION_TOKEN=foo hermes web → _SESSION_TOKEN == "foo", SPA HTML embeds "foo", curl -H 'Authorization: Bearer foo' /api/env → 200
• Empty env var (HERMES_SESSION_TOKEN=) → falls back to random (truthy-or)
• Existing hmac.compare_digest timing-safe comparison path unchanged