app: session route fetches a session that is still being created, logging a 404

Description

Summary

Opening a newly created session from the web app's new-session composer sends a
GET /api/session/<id> that races the POST /api/session creating it. The GET
commonly returns 404 even though the session exists milliseconds later.

Expected Behavior

The route should not request session metadata before the session exists. The first
GET /api/session/<id> should land after POST /api/session commits and return 200.

Actual Behavior

GET /api/session/<id> is sent right after navigation and returns 404 while the
create request is still in flight. From a local run:

Additional Context

packages/app/src/shell/titlebar/titlebar.tsx (the loadedSession resource)
calls ctx.sdk.api.session.get({ sessionID: route.sessionId }) directly, bypassing
data.session. It therefore misses the guard that data.session.create() installs
in packages/client/src/solid/data.ts
(sync.complete("session.family|pending|message:<id>")).

The preparing() check only covers tabs.pendingSession, i.e. the "new worktree"
path. A plain main-worktree new session has no pending entry, so the resource runs
as soon as the route mounts.

The session route's own resolver (packages/app/src/session/session-resolution.ts)
goes through store.sync / message.sync / pending.sync, which the guard
suppresses, so it does not fetch during creation. Verified locally: during a create
those three issue no request, while the raw api.session.get(...) issues one
immediately. The working pattern already exists in
packages/app/src/shell/titlebar/tab-strip.tsx, which uses ctx.data.session.sync(id).

Frequency: the redundant request happens on every new-session submit; whether it
returns 404 depends on the create/GET timing race, so it is intermittent in manual
use. The fetch has .catch(() => {}), so it usually surfaces as a stray 404 in the
Network tab rather than a visible error.

Workaround: reload the session URL after creation completes.

Plugins

none

OpenCode version

vlocal, checkout at v2.0.2

Steps to reproduce

1. Run the local server from the repo, e.g. bun run --conditions=browser packages/cli/src/index.ts serve.
2. Open the web app, start a new session from /new-session (main worktree, not "new worktree").
3. Submit a prompt so the route navigates to /server/<serverKey>/session/<id>.
4. In the browser Network tab, observe GET /api/session/<id> fire immediately and return 404.

Screenshot and/or share link

No response

Operating System

macOS Darwin 24.6.0 (arm64)

Terminal

web UI in browser (TERM_PROGRAM not set in shell env). Shell: /bin/zsh