Backend dashboard process (hermes_cli.main dashboard) survives app quit/relaunch, causing permanently stale in-process caches (e.g. Chromium detection)

Summary

Quitting and relaunching Hermes Desktop (or restarting it via npm run dev) does not actually restart the backend hermes_cli.main dashboard Python process — it keeps running as an orphan across restarts. Since this process holds various in-memory, process-lifetime caches (e.g. Chromium-install detection in tools/browser_tool_install.py's _chromium_installed()), those caches go permanently stale and never get refreshed no matter how many times the app is quit/reopened, until the orphaned process is killed manually.

Environment

• hermes-desktop: 0.7.7 (npm run dev, Windows 11)
• hermes-agent: 0.21.3

Concrete repro that surfaced this

1. Browser Automation's Chromium wasn't installed yet → browser_exec correctly reported "Chromium browser is missing"
2. Installed Chromium (npx agent-browser install --with-deps + npx playwright install chromium) while the app was running
3. Quit Hermes Desktop fully (clicked Quit) and relaunched it (npm run dev again) — expecting the stale "missing" cache to clear
4. browser_exec still reported Chromium as missing, identically, across multiple more full quit/relaunch cycles
5. Checked running processes directly (Get-CimInstance Win32_Process) and found the Electron process tree did fully exit and restart each time, but a pythonw.exe -m hermes_cli.main dashboard --isolated --no-open --host 127.0.0.1 --port 58471 ... process (plus its tui_gateway.slash_worker child) was still alive from the very first app launch, hours earlier — it was never terminated by any of the app quits
6. Manually killed that dashboard process tree; the app spawned a fresh one on the next request, and browser_exec immediately detected Chromium correctly

Expected behavior

Quitting the app (or at least a full quit-and-relaunch, not just closing a window) should terminate the backend dashboard/gateway process tree, so a relaunch gets a fresh process with correctly re-evaluated state instead of an indefinitely-stale one.

Workaround

Find and kill the orphaned pythonw.exe ... hermes_cli.main dashboard ... process (and its tui_gateway.slash_worker / kernel-runner children) manually, then relaunch the app.

Notes

This class of bug likely affects any process-lifetime cache in the backend, not just Chromium detection — worth auditing for other similar one-shot checks that assume a fresh process per app session.