fix(dashboard): keep session DB reads off event loop

[0-CYBERDYNE-SYSTEMS-0]

Summary

Fix a dashboard event-loop starvation path caused by session database reads during desktop startup.

• Move /api/status active-session counting into a worker thread with asyncio.to_thread(...).
• Convert /api/sessions and /api/profiles/sessions to sync FastAPI handlers so their blocking SessionDB work runs in FastAPI's worker pool.
• Add a regression test that makes SessionDB.list_sessions_rich(...) slow and proves another API request can respond before that slow DB read finishes.

Root cause

The desktop can see the backend port listening and the dashboard ready signal while later API calls still silently time out. One uncovered cause is synchronous SessionDB work running inside async FastAPI handlers, starving the event loop during status/session reads. In the reproduced failure, a slow SessionDB.list_sessions_rich(...) delayed an unrelated API request until the DB read completed.

Relation to existing PRs

This complements, but does not duplicate:

• fix(desktop): raise authenticated fetch timeout so profile-heavy remote startup doesn't time out (fixes #48504) #48526, which raises the Electron default authenticated fetch timeout.
• fix(dashboard): move sync I/O off the event loop to prevent desktop timeouts #50948, which moves other dashboard sync I/O off the event loop.

This PR keeps the scope to session/status DB reads and their regression coverage.

Verification

python -m pytest tests/hermes_cli/test_web_server_boot_handshake.py -q -o 'addopts='
python -m py_compile hermes_cli/web_server.py tests/hermes_cli/test_web_server_boot_handshake.py
git diff --check origin/main...HEAD

Results: focused pytest passed (4 passed), py_compile passed, and diff check passed.

[tonydwb]

Code Review Summary

Verdict: Approved

Clean refactoring: moves blocking SQLite SessionDB queries off the async event loop using asyncio.to_thread. The extraction of _count_active_sessions() as a sync helper is the right pattern. The two sync get_sessions / get_profiles_sessions route handlers correctly dropped the async keyword since they do synchronous DB work. Test confirms the event loop is not blocked (version endpoint completes within timeout).

---

Reviewed by Hermes Agent

[alt-glitch]

This was generated by AI during triage.

Related: #50948 (moves other dashboard sync I/O off the event loop), #45491 (offloads cron profile scans), and the umbrella RFC #48564 (dashboard/TUI event-loop-starvation hardening). This PR is scoped specifically to session/status DB reads, so it complements rather than duplicates those — the cluster as a whole is chipping away at the same desktop-startup event-loop-starvation class.

[kshitijk4poor]

Merged via #60884 (rebase) — the residual hunk of this PR (the GET /api/sessions sync-def flip) landed on main as 24d5bda under your authorship. Your other two hunks were already covered: get_profiles_sessions landed earlier via #54523/1bb7b59c5, and the get_status offload was superseded by #58238's read-only + timeout variant (merged in the same batch). Thanks!