fix(desktop): navigate when resuming selected session from non-session page

[re-ITRT]

The Bug

When the user is viewing a non-session page (e.g. /messaging) and clicks the already-selected session in the sidebar, focusOpenSession short-circuits with revealTreePane("workspace") instead of navigating. This leaves the URL at /messaging, so the sidebar highlight (which reads currentView from the pathname) doesn't update and the user appears to be stuck — only the previous session is affected since $selectedStoredSessionId still points to it.

Click session A → /messaging ($selectedStoredSessionId still "A")
 → focusOpenSession("A") → matches selected → return true (skip navigate)
 → sidebar highlight doesn't move (URL still /messaging)  ← BUG

But clicking any other session works fine because $selectedStoredSessionId doesn't match → focusOpenSession returns false → navigate(sessionRoute(B)) executes normally.

The Fix

In focusOpenSession's second branch (the "already selected" shortcut), check if the current URL is actually a session route before returning true:

if (routeSessionId(window.location.pathname)) {
    revealTreePane("workspace")
    noteActiveTreeGroup(null)
    return true
}
return false  // → caller navigates → URL updates → highlight moves

Deeper Discussion — Is This the Real Root Cause?

This fix is correct but operates at the decision layer, not the data source layer. The deeper question: why is the sidebar highlight reading from the URL at all?

The URL and the pane layout tree are two separate state sources. revealTreePane("workspace") changes the layout tree but not the URL. The sidebar reads currentView from appViewForPath(pathname), which reads the URL — so even though the workspace pane is revealed, the URL hasn't changed and the highlight doesn't move.

A true "fix the data source" approach would make the sidebar read from $selectedStoredSessionId directly (or the pane tree) instead of deriving currentView from the URL. That change is broader — it touches SidebarSurface, appViewForPath, and the currentView plumbing — and belongs in a separate cleanup. The fix here avoids that larger refactor while completely resolving the user-visible symptom: clicks that silently don't work.

Root cause chain:

1. Navigating from session A to /messaging does not clear $selectedStoredSessionId
2. focusOpenSession assumes matching selectedId ⇒ workspace pane is the current view — wrong when a route tile is focused
3. Sidebar reads highlight state from URL, not from the session store — so pane-only operations can't update it

This fix addresses #2 at the right layer (the decision function that controls whether to navigate). #1 and #3 are deeper architectural topics for future work.

[alt-glitch]

This was generated by AI during triage.

Related: #66880 addresses the same full-page session-resume symptom, but the live patches differ on open-tile semantics: #66880 preserves an open tile and returns to the main session, while this change falls through to navigate to the clicked session. Maintainer decision needed.

[re-ITRT]

This PR was created by an automated process error. Sorry for the noise.

[re-ITRT]

Thanks for the triage note. The same fix was resubmitted as #68738 with 7 regression tests and a detailed comparison with #66880. Summary of the difference: - #66880 patches the caller (onResumeSession in wiring.tsx) — it compensates for focusOpenSession's incorrect return downstream. - #68738 fixes the decision function itself (focusOpenSession) by checking routeSessionId(window.location.pathname) before returning true. All callers benefit automatically. Both approaches resolve the symptom, but the architectural root belongs in focusOpenSession — the bug is that it assumes matching $selectedStoredSessionId means the workspace pane is the current view, which is false when a route tile is focused. The 7 tests cover: tile session, selected session on session route, selected session on /messaging, selected session on /skills, unmatched session, no selected session, and tile session on non-session route. PR: #68738