Return to the last visited session instead of the first site

[bcotrim]

Related issues

• Related to STU-1985 — extracted from Agentic UI: Simplify Sidebar with new Site-Centric Focus #3998 as part of splitting it into smaller PRs.

How AI was used in this PR

The core change was cherry-picked from #3998 (authored there with AI assistance). Claude Code ported it onto trunk, resolved the one merge conflict, and wrote the unit tests for the redirect/validation logic. All code was reviewed and verified locally (lint, typecheck, apps/ui test suite).

Proposed Changes

Studio's agentic UI always lands on the first site's newest session at launch, regardless of where the user was working. This PR makes the app reopen where the user left off:

• The dashboard remembers the last visited session (or site, for new-chat routes) in localStorage.
• On launch, the / index route redirects back there — after validating against live data. If the last visited session is gone or archived, it falls back to the last visited site's newest active session; if that site is gone too, to the existing default (first site's newest active session).

No launch-time cost: the index route already fetched sites and sessions before redirecting; this adds only a synchronous localStorage read.

Notes:

• The fallback now also skips archived sessions (one line pulled forward from Agentic UI: Simplify Sidebar with new Site-Centric Focus #3998). Without it, an archived last-visited session that correctly falls through validation would be re-selected by the fallback, since it can still be the site's newest session.
• Sessions are not archived when their site is deleted (yet), so deleting the site you were last on means relaunch lands back on that now-orphaned session. The session view handles this gracefully (name-only header, no site dropdown). The archive-chats-on-site-delete follow-up to STU-1985 closes this hole properly.

Testing Instructions

1. Launch Studio with the agentic UI and open a chat session on a site other than the first one in the sidebar.
2. Quit and relaunch — you should land back on that same session.
3. Start a new chat on a site (without sending a message), relaunch — you should land on a new chat for that same site.
4. Archive the session you were on, relaunch — you should land on that same site's newest remaining active session (or a new chat for it if none are left), with no errors.
5. Archive the session and delete the site, relaunch — you should fall back to the first site's newest active session, with no errors.
6. Delete the site you were on without archiving the session, relaunch — you land back on that session with a name-only header (see Notes above), with no errors.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

🤖 Generated with Claude Code

[wpmobilebot]

📊 Performance Test Results

Comparing 6b53f3a vs trunk

app-size

Metric	trunk	6b53f3a	Diff	Change
App Size (Mac)	1419.26 MB	1419.26 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	6b53f3a	Diff	Change
load	1089 ms	1091 ms	+2 ms	⚪ 0.0%

site-startup

Metric	trunk	6b53f3a	Diff	Change
siteCreation	7006 ms	7005 ms	1 ms	⚪ 0.0%
siteStartup	2351 ms	2356 ms	+5 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[katinthehatsite]

Delete the site you were on without archiving the session, relaunch — you land back on that session with a name-only header (see Notes above), with no errors.

I seem to land on name-only session for that canse but then I can still send messages and they go into the Unassigned section (so the local site is deleted but I can send messages):

When I am asking the chat about it, it says the site no longer exists (I guess it makes sense that it is now Unassigned):

But I am finding the experience a bit strange, should be disable the input field in that case? I am guessing part of the problem will be solved when we delete the sessions when the user deletes the site in a different PR I review earlier.