fix(desktop): navigate to session when clicking most-recent from non-Chat tab

[kyssta-exe]

Problem

When viewing a non-Chat tab (Plugins, Artifacts, Capabilities, Messaging) and clicking the most recent session in the sidebar, nothing happened — the view stayed on the current page (/plugins, /artifacts, etc.).

Clicking any other session worked fine: it switched to Chat with that session loaded.

Root Cause

The onResumeSession callback at wiring.tsx:753 calls focusOpenSession(sessionId) first. When the clicked session matches $selectedStoredSessionId (i.e. it's the most recent / last-opened session), focusOpenSession returns true after calling revealTreePane('workspace') and noteActiveTreeGroup(null) — but it does not navigate the router. Since the user is on a non-Chat page, the workspace pane doesn't show chat, so nothing visible happens.

For sessions that differ from $selectedStoredSessionId (all but the topmost), focusOpenSession returns false, and navigate(sessionRoute(sessionId)) runs as expected.

Fix

After focusOpenSession returns true but the current route is NOT a chat view, still call navigate(sessionRoute(sessionId)) to force the route change. This is a 2-line addition in the existing handler.

Test

TypeScript compiles cleanly (npx tsc --noEmit passes). No test coverage exists for this specific wiring handler path.

Closes #66875

[alt-glitch]

This was generated by AI during triage.

Duplicate of #66880: both repair the focusOpenSession success path that leaves a non-Chat route visible when the latest session is selected. #66880 is the earlier open implementation with focused regression coverage.

[teknium1]

Thanks for the focused fix. The dead-click premise is confirmed on current main: apps/desktop/src/app/contrib/wiring.tsx:753-756 only navigates when focusOpenSession returns false, while apps/desktop/src/store/session-states.ts:424-447 returns true for both the main session and open tiles.

Problems

• apps/desktop/src/app/contrib/wiring.tsx:761 routes an already-open tile to sessionRoute(sessionId). After focusOpenSession has focused that tile, apps/desktop/src/app/session/hooks/use-route-resume.ts:115-150 treats the tile route as non-active and calls resumeSession; apps/desktop/src/app/session/hooks/use-session-actions/index.ts:446-450 then makes it the selected/main session. The requested view switch should not promote an existing tile.
• The changed routing decision has no regression coverage.

Suggested changes

• Route the non-chat, already-open path through the selected main-session route, falling back to the clicked id only if no main session exists.
• Add focused pure routing tests. The earlier open implementation in #66880 (c39e7273c1e4d3743004a17831cf2a8cfe383828) covers the main-session, tile, and no-main cases.

Automated hermes-sweeper review.

[teknium1]

For an already-open tile, this routes to the tile id after focusOpenSession has focused it. useRouteResume then resumes that id as the selected/main session, promoting the tile. Route through the selected main-session id here (with a no-main fallback) so this only reveals Chat while preserving the tile.

[kyssta-exe]

Closing as duplicate of #66880 (alt-glitch triage confirmed). The focusOpenSession success-path fix is already covered there.