fix(server): read gateway bearer token at request time and honor HERMES_API_TOKEN

[eudigitalis]

Summary

src/server/openai-compat-api.ts has two issues that combine to break the chat surface for any deployment whose Hermes Agent gateway has API_SERVER_KEY set (i.e. anything that isn't an open loopback gateway):

1. The local BEARER_TOKEN const reads only CLAUDE_API_TOKEN, ignoring the documented HERMES_API_TOKEN env var that the README ("attach the workspace to existing hermes-agent") and the .env.example tell users to set. Looks like a leftover from the Claude → Hermes rename: the analogous const in src/server/gateway-capabilities.ts:222 honors both names, but this local one was never updated.

2. The const is evaluated at module-load time. Under vite-node SSR (pnpm dev), the module can be loaded in a worker context where process.env doesn't yet contain the values that systemd / EnvironmentFile / .env populated for the parent node process. That freezes the constant to '' permanently, even though the env is correctly populated by the time openaiChat actually runs.

Symptom

Chat UI loads, sessions/skills/memory all work, but every message produces a run with status: error and:

errorMessage: "OpenAI-compatible chat: 401 {\"error\": {..., \"code\": \"invalid_api_key\"}}"

…in <HERMES_HOME>/webui-mvp/runs/<session>/<run>.json. The error format matches what the gateway returns for missing Authorization, not an upstream provider error.

Confirmed via instrumentation in the request handler:

[DEBUG-AUTH] BEARER_TOKEN length: 0
             env.HERMES_API_TOKEN length: 16

Same process.env, two different observed values — the const captured an empty snapshot.

Repro

1. Run hermes-agent gateway with API_SERVER_KEY=<anything> (so the gateway requires Authorization: Bearer)
2. Set HERMES_API_TOKEN=<same> in workspace .env
3. pnpm dev
4. Open chat, send a message → 401 in webui-mvp/runs/<session>/

Fix

Replace the const with a small getBearerToken() helper that reads env at call time and honors HERMES_API_TOKEN with fallback to CLAUDE_API_TOKEN. Three call sites updated (getDefaultModel, openaiChat Authorization header, and the session-id guard).

No behavior change for setups that already worked (open loopback gateway with no API_SERVER_KEY, or production builds where process.env is fully populated before module load).

Test plan

• pnpm exec tsc --noEmit — passes for the changed file
• Manual: with API_SERVER_KEY set on the gateway and HERMES_API_TOKEN set on the workspace, chat works end-to-end via pnpm dev (was 401 before, 200 after)
• Manual: with no API_SERVER_KEY (loopback / portable), behavior unchanged