fix(desktop): preserve profile when resuming chat sessions

[nxtlevel-starfleet]

Summary

Fix Desktop Chat resume routing so sessions from named/default profiles keep their owning profile when resumed from the dashboard.

This change:

• preserves the session row's owning profile when Chat sidebar and Sessions page links navigate to /chat?resume=...;
• adds a best-effort owner-profile lookup for stale/unscoped resume URLs before opening the PTY;
• adds a server-side fallback in /api/pty that infers the unique local profile owning the resume session;
• resolves latest-descendant session IDs inside the requested profile DB instead of always using the dashboard process DB;
• preserves legacy behavior for ambiguous/no-match lookups and for profile=current.

Why

Desktop can list/manage sessions across profiles, but the Chat resume path previously navigated with only resume=<session_id>. In a multi-profile install that can spawn the PTY under the dashboard/current profile rather than the session owner's profile, so the resumed TUI may load the wrong config, skills, memory, and state DB.

Validation

• python -m pytest tests/hermes_cli/test_web_server_profile_unification.py tests/hermes_cli/test_web_server_pty_reconnect.py -q → 40 passed, 3 warnings
• python -m ruff check hermes_cli/web_server.py tests/hermes_cli/test_web_server_profile_unification.py
• python -m py_compile hermes_cli/web_server.py tests/hermes_cli/test_web_server_profile_unification.py
• git diff --check
• npm --prefix web run typecheck

Notes

The inference helper returns a profile only when exactly one local profile DB contains the target session. Ambiguous or missing matches fall back to the legacy unscoped path rather than guessing.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #48049 — both patch the same code-site in hermes_cli/web_server.py (and the same test file tests/hermes_cli/test_web_server_profile_unification.py): making _session_latest_descendant(session_id, profile=...) resolve inside the requested profile's state DB, adding a cold-path owning-profile inference for stale/unscoped resume URLs, and scoping the latest-descendant endpoint by ?profile=. #48049 (open, earlier) is canonical. The extra web/src/* frontend plumbing here builds on the same server-side fix. Related: #49619, #48473 (cross-profile desktop resume cluster).

[teknium1]

Thanks for preserving the owner profile through dashboard resume links. The current-head premise remains: named-profile session rows are tagged with profile in hermes_cli/web_server.py:4082-4084, but both resume navigators discard it (web/src/components/ChatSessionList.tsx:115-123 and web/src/pages/SessionsPage.tsx:452-455). Current PTY startup only scopes HERMES_HOME when it receives a profile (hermes_cli/web_server.py:14801-14809,14847-14860), so a durable unscoped resume URL still lacks the owner information.

The proposed explicit URL propagation fits the existing ProfileProvider contract, which treats ?profile= as a deep-linkable management scope (web/src/contexts/ProfileProvider.tsx:15-27,42-60). Its ambiguous-owner behavior is appropriately conservative: current main explicitly tests duplicate session IDs in different profiles (tests/hermes_cli/test_web_server.py:1458-1483), so inference must not choose a first match.

A member has identified open #48049 as the canonical related PR; maintainers should reconcile the overlapping server-side implementation during salvage. This is an automated hermes-sweeper review.