fix(tui): distinguish location loading from data sync failures

[kitlangton]

Why

When /api/location succeeds but /api/agent returns HTTP 500, the TUI replaces the composer with “Session location unavailable” and tells the user to choose another directory. Moving does not address that catalog failure, and the user loses access to their draft while the panel is shown.

What Changes

Failure	Behavior
Location loads, then agent/model/MCP or another data request fails	Keep the resolved location and composer. Show Session data sync failed with a Retry action.
Location loading itself fails	Show Could not load session location, with Retry and optional Choose directory. Do not infer that an HTTP 500 means the directory is absent.
A request from a previous placement or connection finishes late	Ignore it. An old toast's Retry cannot sync a different placement.

The existing syncInfo/sync boundary is enough to distinguish these cases: successful location info stays cached, while failed reads remain retryable. Original causes remain available in location state or logs. Disconnect invalidates the existing attempt generation before the buffered reconnect event arrives.

Demo

location-sync-comparison.mp4

Before: d9c85d8d95. After: d036479eff. Both run the production TUI through the same deterministic OpenCode Drive fixture at 100×30, with a simulated provider and a loopback HTTP proxy returning 500 only for /api/agent; /api/location succeeds. After the endpoint is healed, the new Retry action reloads it without losing the draft. Equal-length clips are shown sequentially to keep terminal text readable; startup is trimmed, not accelerated.

Scope

Overlaps #45601, but keeps this fix TUI-local: no new protocol errors, filesystem probes, client generation, or server cache changes. In particular, the existing server can still return cached location info after a booted directory is deleted; this PR does not add deletion detection or claim to resolve the separate, unconfirmed unknown-shell incident.

Verification

bun install --frozen-lockfile
cd packages/tui
bun run test test/session-location-sync.test.tsx test/context/location.test.tsx
bun run test test/cli/tui/data.test.tsx test/context/session-tabs.test.tsx test/component/session-tabs-status.test.tsx test/cli/tui/composer-keymap.test.tsx test/cli/tui/prompt-move.test.tsx test/new-session-location.test.ts
bun run test
bun typecheck

• Red on base: the six production-TUI transport cases fail on d9c85d8d95 with the old directory-recovery panel.
• Focused: 10 passed, repeated three consecutive times. Includes initial and reconnect failures, agent/model/MCP failures, composer identity and draft preservation, rendered Retry/Choose directory clicks, repeated failed retries followed by recovery, original-cause identity, and stale-request/old-Retry isolation. A deterministic test also reproduced the connection-ready/buffered-event gap before fixing it.
• Broader: 101 relevant tests passed; the complete TUI suite passed 1,185 tests, with 4 skipped and 2 snapshots.
• Types: TUI package check passed. The unmodified pre-push hook passed all 33 workspace typecheck tasks, including its normal cache reuse.
• Real isolated server check: a previously unseen absent directory fails; creating it permits resolution. Deleting an already-booted directory still returns cached success, and restoring it succeeds. No production service restart or live-session mutation was used.