Add programmatic TUI sync/refresh for externally-updated threads

Problem

When codex app-server and TUI operate as separate processes, they can resume the same threadId independently, but there is no supported way to programmatically trigger the running TUI to refresh/re-sync from updated rollout state.

Today, users must manually use /resume (or restart TUI with codex resume ...) to pick up changes written by another process.

Why this matters

• Multi-client workflows (TUI + app-server/IDE integration) are increasingly common.
• Without programmatic sync, users see stale state in TUI and can accidentally diverge thread state.
• "Same threadId" is misleading if process-local in-memory state cannot be refreshed on demand.

Current behavior

• Cross-process updates are only eventually visible via manual resume/reload.
• No external API/IPC to ask a live TUI process to sync a specific thread.

Proposal

Add a supported programmatic sync mechanism for TUI, for example one of:

1. New CLI command targeting a running TUI instance (IPC):

• codex tui sync --thread-id <id>

1. New app-server method that can signal TUI process(es) to refresh a thread:

• thread/sync (or similar)

1. Optional file/watch-based trigger that TUI can subscribe to and auto-refresh safely.

Suggested semantics

• Sync is explicit and idempotent.
• If active turn is in progress, either:
• queue sync until turn completion, or
• return a clear "busy" error.
• Surface result status (synced, queued, busy, thread_not_found, etc.).
• Preserve user cursor/composer state where possible.

Acceptance criteria

• A live TUI instance can be triggered externally to refresh a specified thread without restart.
• The refresh path is documented.
• Behavior is deterministic when both TUI and app-server touch the same thread.
• Includes integration test coverage for cross-process sync workflow.

Notes

This is not asking for shared in-memory runtime across processes; just a safe, supported, programmatic re-sync trigger for live TUI.