Let the web UI work when an api secret is configured

[comstud]

Setting http_listener.secret gated the whole /api group behind the X-Rotom-Secret header, but the UI is served from the same listener and made bare fetch() calls with no headers. The SPA loaded and then every request 401'd, so enabling the secret made the dashboard unusable.

The middleware now accepts any one of three credentials:

X-Rotom-Secret machine clients, unchanged
Authorization: Bearer clients preferring a short-lived
token to a static secret
session cookie + X-Rotom-Session the web UI

Sessions are HS256 tokens in an HttpOnly, SameSite=Strict cookie, minted by POST /api/auth/login in exchange for the configured secret. HttpOnly means an XSS bug in the UI cannot exfiltrate the credential; the secret itself is never persisted anywhere page JavaScript can reach.

The signing key is derived from the secret rather than generated at startup, which makes sessions survive a restart and makes rotating http_listener.secret -- including via config reload -- invalidate every outstanding token. That is the only revocation mechanism a stateless token has.

Session lifetime is http_listener.ui_session_ttl, defaulting to one day. It is written "24h" rather than "1d" because Go duration syntax has no day unit. The value governs both the token's exp claim and the cookie's Max-Age so the two cannot drift apart, and it is re-read on config reload. Because expiry is signed into each token, shortening the TTL applies to subsequent logins only; it does not retroactively end sessions already issued.

Tokens are hand-rolled rather than pulling in a JWT dependency: only one algorithm is ever minted or accepted, and requiring exactly HS256 up front sidesteps the alg-confusion footguns a general-purpose parser brings. No new Go module, no vendor churn.

Cookie-authenticated requests must also carry X-Rotom-Session. The browser attaches the cookie on its own, so without that check a cross-site form post would ride a logged-in operator's session; a custom header cannot be set cross-origin without a preflight we never answer. Requests authenticated by header or bearer token do not need it.

The session endpoints are registered on their own unauthenticated /api group -- as a separate group rather than relying on gin capturing middleware at registration time, so a later reordering cannot silently gate the only path back in.

On the UI side, AuthGate swaps the rendered tree in place instead of routing to /login. The URL never changes, so a session expiring mid-poll leaves the operator where they were and a deep link survives login with no return-to-path plumbing. It watches the query and mutation caches for 401s, so an expired cookie surfaces as the login form without every page handling auth itself.

Deployments with no secret configured are unaffected: the server reports auth_required=false and the UI renders straight through.

Verified against the built binary with the embedded UI: bare requests 401, login sets the hardened cookie, cookie+header reaches both reads and mutating PUTs, the same PUT without the header is refused, a config reload that changes the secret drops live sessions, and a configured ui_session_ttl of "5s" both lands on the cookie and expires the session server-side.

Claude-Session: https://claude.ai/code/session_014usJRTkZk7Zgi7zUwWfY5n