fix(update): preserve dashboard session token on respawn

[mazikooooo]

Summary

Preserve an explicitly injected HERMES_DASHBOARD_SESSION_TOKEN when hermes update respawns a manually started hermes dashboard or hermes serve process.

Without this, the replacement backend can remain HTTP-healthy while Hermes Desktop loses authenticated WebSocket access because the updater inherited different launch-time state than the old backend.

Root cause

The update path already captures each manual backend's argv before stopping stale code, then respawns that argv after the update. Process-only authentication state was not captured, so the replacement inherited only the updater's environment.

Changes

• Best-effort read the old backend's non-empty dashboard session token before termination.
• Keep tokens associated with their corresponding PID/respawn command.
• Build each replacement environment from the updater environment and override only the allowlisted token.
• Fall back to existing argv respawn behavior when process environment inspection is unavailable or denied.
• Keep systemd-managed, Electron-managed, Windows, --stop, --no-open, and failure-reporting paths unchanged.

Security

• No full old-process environment is retained or forwarded.
• The token is not placed in argv, printed, logged, serialized, or persisted.
• Unrelated variables from the old backend are not copied.

Tests

• Added regression coverage for two manual backends with distinct tokens.
• Added denied-environment-inspection fallback coverage.
• 29 passed, 3 skipped in test_update_stale_dashboard.py (includes the upstream [Bug]: hermes update respawns every orphan hermes serve --port 0, accumulating backends across updates #78821 respawn-filter tests, unchanged and green).
• 11 passed across test_dashboard_lifecycle_flags.py + test_lazy_command_exports.py.
• git diff --check passes.

Rebase note (2026-08-15)

Rebased onto current main (post-#78821 respawn filtering). Tokens are now
captured alongside the argv/HERMES_HOME pre-kill snapshots and re-attached
to the filtered respawn commands by normalized cmdline (first occurrence wins,
matching the filter's dedupe order). When no token was captured, the respawn
call keeps its original bare-argv form, so existing callers and mocks are
unaffected. New tests also carry the class's POSIX skipif markers.

Platforms

Tested on WSL2/Linux. The existing native-Windows manual-respawn exclusion is unchanged; native macOS and Windows were not exercised locally.

Related work

This is deliberately narrower than #54034. It does not persist generated session tokens across arbitrary daemon restarts; it preserves an explicitly injected token only across the existing manual update-respawn transaction.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(update): preserve dashboard session token on respawn

1. hermes_cli/dashboard_procs.py — token attribution is by normalized cmdline with "first occurrence wins". If two stale dashboard processes share the same normalized cmdline (e.g. both hermes dashboard with no distinguishing args), both respawns receive the first process's token — one user could be handed another user's dashboard session. If _normalize_dashboard_cmdline does not already include the distinguishing bits (port, profile, HERMES_HOME), consider skipping token preservation when the cmdline is ambiguous rather than mis-attributing.

2. hermes_cli/main.py _dashboard_session_token_for_pid — reading the dying process's environment via psutil is inherently racy (the process can exit between _find_stale_dashboard_pids and the environ() read) and the except Exception → None fallback correctly degrades to the bare-argv path. Good. One note: the captured token is forwarded verbatim to the respawned process; if the killed process's token was already stale/expired, the respawn inherits an invalid token and the dashboard session silently fails auth. Consider having the respawned dashboard re-validate (or refresh) the token rather than trusting it.

3. The tests cover per-process token preservation, env isolation (no OLD_PROCESS_ONLY leakage), and the environment-inspection-failure fallback — solid coverage for the main risk paths.

No blocking issues found.