fix(dashboard): resume chat in the session's owning profile

[cyb0rgk1tty]

What

Reopening a dashboard chat that belongs to a different profile than the one currently selected in the profile switcher fails with "session not found." The desktop app hits this too: it restores its last /chat?resume=<id> URL on launch, which carries no ?profile=, so the resume is scoped to whatever profile happens to be sticky-active.

Root cause: sessions are stored in per-profile state.db files, but the resume path resolved them only against the process/active profile:

• _session_latest_descendant() always opened the process db, and /api/sessions/{id}/latest-descendant took no profile argument.
• _resolve_chat_argv() bound HERMES_HOME from the switcher hint, so the spawned TUI reopened the wrong state.db and 404'd.

Fix

• _session_latest_descendant(session_id, profile=None) opens the requested profile's db and, on a miss, falls back to locating the owning profile and walking the compression chain there. Session ids are globally unique, so this is safe.
• /api/sessions/{id}/latest-descendant accepts ?profile=, matching the sibling read endpoints (/messages, detail).
• _resolve_chat_argv() resolves a resume target's owning profile and pins HERMES_HOME to it explicitly (including the default home), so the spawned TUI reopens the correct state.db regardless of the hint. Named owners still spawn their own gateway; default-owned resumes keep the in-memory gateway attach.
• New _find_session_profile(): read-only point-lookup across profiles (no table scan, no descendant walk), used only on the cold path.

Repro

1. Have a session in the default profile and a non-default profile active in the switcher (or open a desktop window whose restored URL is /chat?resume=<default-session-id> with no ?profile=).
2. Resume that session. Before: session not found. After: resumes correctly.

Scope / relation to other PRs

This is the resume / chat-PTY half of cross-profile session handling. It complements #44162 (the transcript-load path — getSessionMessages, for #44147); the two don't overlap in code. A frontend change could additionally thread the owning profile into the resume URL to skip the lookup, but the server-side fix makes resume correct even for bookmarked / desktop-restored URLs that carry no profile.

Testing

• New regression tests in tests/hermes_cli/test_web_server_profile_unification.py::TestProfileScopedChatResume: owner lookup; latest-descendant resolution in / without / with-wrong profile; the endpoint's ?profile= honoring + no-profile fallback; and _resolve_chat_argv binding the owner for both named- and default-owned resumes.
• scripts/run_tests.sh tests/hermes_cli/test_web_server.py tests/hermes_cli/test_web_server_profile_unification.py — pass (3 unrelated, pre-existing failures in the status/update-hermes endpoints reproduce on main without this change).
• scripts/check-windows-footguns.py hermes_cli/web_server.py — clean.

[alt-glitch]

Related: #44162 (the transcript-load half — getSessionMessages, for #44147). This PR is the resume / chat-PTY half of cross-profile session handling; per the description the two don't overlap in code, so they're complementary rather than duplicates.

[teknium1]

Thanks for isolating the dashboard PTY resume path. The current-head premise is still visible: the PTY forwards profile into _resolve_chat_argv (hermes_cli/web_server.py:15483-15512), which scopes both descendant lookup and HERMES_HOME to that one profile (hermes_cli/web_server.py:14618-14631).

Problems

• The proposed owner fallback relies on globally unique session IDs, but current main deliberately creates shared-root in both the default and worker profile (tests/hermes_cli/test_web_server.py:1303-1328). A first-match _find_session_profile() can therefore resume the wrong session or compression lineage.
• Main already uses explicit profile scoping in the dashboard path (web/src/pages/ChatPage.tsx:904-915), and commit 6015ee5d repaired descendant lookup to use that scoped database. Overriding an explicit scope based on an ambiguous ID would conflict with that routing model.

Suggested changes

• Carry an explicit profile with durable resume links/restored state instead of discovering an owner from a raw session ID.
• Add a duplicate-ID cross-profile regression proving that a resume never silently crosses profile boundaries.

Automated hermes-sweeper review.