fix(app): recover invalid session routes

[opencode-agent]

Malformed or temporarily unavailable server route segments currently throw outside the session error boundary and crash the entire desktop renderer.

This change adds non-throwing server-key parsing at the outer route boundary and redirects invalid or unavailable server routes home, while preserving strict parsing for callers that require a valid key.

Tests:

• bun test --conditions=solid --preload ./happydom.ts ./src/shell/routes/session.test.ts
• bun typecheck

[Enough1122]

AI code review — automated review for reference; please use your judgment.

1. packages/app/src/shell/routes/routes.tsx:54 — fallback={<Navigate href="/" />} fires whenever the connection lookup misses — including transiently, e.g. while global.servers is still loading at app boot. A structurally valid deep link can then bounce the user home depending on timing. Why it matters: recovery for garbage keys (good) becomes indistinguishable from "server not loaded yet" (bad). Suggestion: only navigate when parseServerKey fails; render a loading/spinner state while the key parses but the registry hasn't settled.

2. packages/app/src/new-session/composer-adapter.ts:73 — tabs.updateDraft(props.draftID, { worktree: undefined }) was dropped entirely, not just moved out of the transition. If promoteDraft removes the draft entry this is fine, but any persisted draft state (composer persistence survives restarts?) may keep a stale worktree. Why it matters: resurrected drafts could reopen against an outdated worktree. Suggestion: confirm removal is intentional and covered by promoteDraft, or keep the clearing step.

3. packages/app/src/shell/tabs/tabs.tsx:234 — promoteDraft is now awaited by callers and internally awaits startTransition; if that transition suspends indefinitely, submission.retarget(...) in the composer adapter never runs and the sent message loses its target. Why it matters: a rare suspense stall turns into a silent lost-submit. Suggestion: document the assumption or bound the wait (e.g. resolve once the store update is applied rather than the full transition).

4. packages/app/src/shell/routes/session.test.ts:15 — New parseServerKey cases are good, but nothing pins the route-level recovery behavior (invalid key ⇒ redirected home instead of thrown). Why it matters: item 1's policy decision lives exactly there, untested. Suggestion: add a small render test asserting <Navigate> fallback on malformed keys and no redirect for well-formed-but-pending keys (per suggested fix).

— automated review (ox-alpha, round2)