fix(dashboard): keep status responsive when session db locks

[tianma-if]

Summary

• move /api/status active-session counting onto a best-effort read-only SessionDB path
• cap the active-session count with a short async timeout so a locked state.db cannot hold the status response
• degrade the non-critical active_sessions field to 0 if the DB is locked or unavailable

Context

Addresses the SessionDB lock path reported in #57203. The existing open PRs for that issue focus on the gateway health probe timeout, but the issue follow-up narrowed the observed 21s delay to SessionDB().list_sessions_rich(limit=50) after read_runtime_status(). This PR targets that separate blocking path.

Tests

• .venv/bin/python -m pytest tests/hermes_cli/test_web_server.py -q -k 'status_active_session_count or get_status_degrades or test_get_status'
• .venv/bin/python -m pytest tests/hermes_cli/test_web_server.py -q
• .venv/bin/python -m py_compile hermes_cli/web_server.py tests/hermes_cli/test_web_server.py
• .venv/bin/python -m ruff check hermes_cli/web_server.py tests/hermes_cli/test_web_server.py
• git diff --check

[tonydwb]

Code Review Summary

Verdict: Comment

Summary

Keeps dashboard status responsive when session db locks by adding a read-only SessionDB connection with its own timeout (_STATUS_ACTIVE_SESSIONS_TIMEOUT = 0.75s) for counting active sessions on /api/status.

Looks Good

• Read-only db connection prevents write contention
• Independent timeout from main gateway health probe
• Best-effort pattern: on timeout, returns 0 gracefully
• Proper executor pattern for async-safe db access
• No security concerns

---

Reviewed by Hermes Agent

[tonydwb]

Code Review Summary

Verdict: Comment (LGTM — token read-only, formal approval deferred to maintainer)

Dashboard status endpoint robustness fix: refactors active session counting into a dedicated async function with a 0.75s timeout and read-only database connection. This prevents /api/status from blocking or competing with write operations during session DB lock contention. The timeout degrades gracefully to 0 with debug logging.

Looks Good

• Read-only SessionDB connection avoids write contention
• Proper timeout on run_in_executor prevents blocking the dashboard response
• Degrades to 0 on timeout or exception (not a hard failure)
• Tests verify read-only flag is passed and lock failures return 0 gracefully

---

Reviewed by Hermes Agent

[kshitijk4poor]

Merged via #60884 (rebase) — your commit landed on main as 9a4341a with your authorship preserved. Follow-up commits on top: a fresh-install guard (read-only opens require state.db to exist) and compact_rows=True in the count query. Thanks!