fix(web): log session-token provenance and hint at stale .env on mismatch

[andrexibiza]

What

Part of the coordinated close for #40680 (stale .env session token poisoning desktop auth). This PR makes the backend say where its token came from and name the fix when a mismatch happens.

• _resolve_session_token() now records provenance: injected (env token + HERMES_DESKTOP=1), env (token present, no desktop marker — includes the stale-.env-clobber case), or generated (fresh random).
• One startup log line: dashboard session token: source=<provenance> length=<n> — never the token value itself.
• On WS auth rejection with token_mismatch in loopback mode, when the server token source is not injected, a WARNING names the likely cause and the fix: a stale HERMES_DASHBOARD_SESSION_TOKEN in <hermes-home>/.env — remove the line or run hermes setup. Existing rejection log line preserved verbatim (compat).

Auth semantics are unchanged — this is diagnostics only.

Dedup/composition note — overlapping open PR #54034 (authored by @Kewe63): #54034 changes the same _SESSION_TOKEN resolve line in the opposite direction (persisting the token across daemon restarts; sweeper-flagged as an unresolved security-boundary decision — keep_open salvageability=medium). This PR is diagnostics-only and deliberately written to compose: the provenance classifier is a pure function (_session_token_source()) that classifies whatever value ends up in _SESSION_TOKEN, so it works identically whether that value came from env, .env, or a future persistence layer. No conflict in direction, but both PRs touch hermes_cli/web_server.py — merge order matters only for whitespace, not semantics.

Reproduction (current vs expected)

Current (pre-fix): a desktop lockout produced exactly one opaque log line — console auth rejected reason=token_mismatch mode=loopback cred=token peer=127.0.0.1 — with no indication that the server token came from a stale .env value. _resolve_session_token() (web_server.py:330) silently took whichever env value won.

Expected (post-fix): the startup log says dashboard session token: source=env length=32 (never the value), and a loopback token_mismatch with source != injected is followed by a WARNING naming the exact fix: a stale HERMES_DASHBOARD_SESSION_TOKEN in <hermes-home>/.env — remove the line or run hermes setup.

How to test

cd <worktree> && <main>/venv/Scripts/python -m pytest tests/hermes_cli/test_web_server.py tests/hermes_cli/test_web_server_console_ws.py -q --no-header -p no:cacheprovider

New unit tests cover: provenance classification for injected/env/generated (pure classifier function, no source-file reads), and the mismatch hint emitted via caplog when source != injected.

Platforms tested

• Windows 11, Python 3.12 — targeted suites green, git diff --check clean, scripts/check-windows-footguns.py hermes_cli/web_server.py clean.

Why this matters to users

Before, a desktop lockout produced one opaque line (console auth rejected reason=token_mismatch) with no hint about the cause — users stared at a dead app for hours. After, the startup log tells you in one line whether the backend is holding your injected token, and a mismatch tells you exactly which file and key to clear.

[andrexibiza]

Superseded by #76958 — this lane's work is consolidated into the single class-closing PR. The commit(s) live on in #76958's branch; no work is lost.