Issue for this PR

Closes #31073

Type of change

• Bug fix

What does this PR do?

After the first successful hydration of a session, sync.session.sync() short-circuits via a fullSyncedSessions set, so updates produced by another opencode client, a remote agent, or opencode serve running the same session never reach this TUI unless they happen to land on its own SSE stream. The session view stays frozen until the user navigates away and back.

The fix:

• Adds an opt-in force?: boolean option to sync.session.sync() (packages/tui/src/context/sync.tsx) that bypasses the once-only cache while still de-duping concurrent in-flight calls via syncingSessions. Default behavior is unchanged for every existing caller.
• Adds a new external_sync_interval_ms key (packages/tui/src/config/index.tsx, range 0-60000, default 2000, 0 disables) so the polling cadence is configurable in tui.json.
• Adds a createEffect in the session route (packages/tui/src/routes/session/index.tsx) that polls sync.session.sync(id, { force: true }) at the configured interval only while the session's status is working or compacting, and uses onCleanup to clear the interval on route change, idle transition, and unmount.

Why it works: the force flag lets the polling effect re-fetch the active session's state on a timer, bypassing the once-only cache that previously made sync.session.sync() a no-op forever after first hydration. The poll is bounded — it only runs while a session is being driven (working / compacting) and stops the moment the session goes idle, the route changes, or the interval is set to 0. When the SSE stream is healthy the local store already has the latest data and the reconcile is incremental, so the poll is effectively a no-op. It exists purely as a safety net for external writers and dropped events.

How did you verify your code works?

• bun test in packages/tui: 190 pass, 1 skip, 0 fail (full suite, no regressions)
• bun test test/cli/cmd/tui/sync.test.tsx test/config.test.tsx: 15 pass, 0 fail (4 new sync tests + 3 new config tests)
• bun run typecheck in packages/tui: clean
• bun typecheck in packages/opencode: clean
• Push triggered monorepo-wide typecheck via Turbo cache: 23/23 tasks successful

The 4 new tests in test/cli/cmd/tui/sync.test.tsx cover the regression directly:

• a second sync(id) call is a no-op (cache hit)
• a sync(id, { force: true }) issues a new round of fetches
• two parallel force: true calls share a single underlying fetch (de-dup)
• a force re-sync after a message.updated SSE event still issues 4 fetches instead of 0

Screenshots / recordings

Not applicable. The bug requires two opencode clients (or one client + opencode serve) writing to the same session, and the fix is invisible to a single TUI running standalone — a screenshot of one TUI cannot show the regression or the fix in action. The change is verified by the 4 new automated tests above.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR