fix(workbench): handle stale workspace resume memory

[wyuc]

Closes #1270.

Problem

Entering the Pro workspace from classic mode resumes the last-opened conversation from localStorage. Two rough edges: a remembered session that no longer exists still navigates to /workspace?session=<id> and fails to load with no fallback; and returning to the workspace home is never remembered, so the next entry resumes the last session again.

Change

1. Stale resume guard — WorkspaceShell validates the session that matched entry memory against the owner session list it already loads (no new endpoint, no duplicate fetch, entry is not blocked). On a miss, validateRememberedWorkspaceSession() forgets the stale id and replaces the route with the clean /workspace home. Direct (unremembered) session links are not affected.
2. Home memory — the existing storage key now accepts a private home sentinel. rememberWorkspaceHome() writes it when both workspace panes are absent; readLastWorkspaceSessionId() maps it back to null, so the classic entry and workspaceResumeHref() keep their existing contracts and resolve to /workspace. Opening a conversation overwrites the sentinel.

All reads/writes/deletes retain best-effort storage-unavailable handling.

Tests

Added unit coverage for the home sentinel and stale-id forget-on-miss in workspace-session-memory, plus shell-level guard coverage. Typecheck, touched-file lint/prettier all clean.

[CXuPercy]

Verified locally against the PR head (worktree + both touched test files, 34/34). This is a clean, well-scoped fix — every load-bearing assumption checked out:

The stale-resume guard triggers exactly where it should. rememberedResumeSessionId is armed only when the URL's session param equals the localStorage memory value — i.e., only memory-driven resumes get validated. A shared deep link to an unremembered session leaves the guard inert, and there's a dedicated test pinning that distinction.

No partial-list false positive — the property I was most worried about. The guard waits for sessionState === 'ready', and in OwnerSessionClient 'ready' is emitted only after a successful full REST fetch ("this snapshot is a full read of the list... Unconditionally authoritative"), so the membership check always sees the complete owner session list, never a partial or stream-only view.

The home sentinel is collision-free and contract-preserving. Real session ids can't equal the sentinel string; readLastWorkspaceSessionId maps it back to null so workspaceResumeHref and the classic entry keep their existing behavior; forgetWorkspaceSession's match-only-delete semantics coexist with the sentinel correctly; opening a conversation overwrites it naturally. The behavior is also self-consistent after the guard fires: the replace-to-home transition lands in the memory effect and writes the home sentinel, which matches "the user's last state was home."

Storage-unavailable handling is retained on every new read/write path, and the "course open without a conversation writes nothing" middle state is documented as deliberate in the description. Nothing to change from my side.