fix(mobile): New threads no longer get stuck on "Starting…" or "Thread unavailable"

[mwolson]

Problem

Fixes #16600. A thread started from the mobile app can stay on its queued prompt with a "Starting…" pill and never show the agent's reply, even though the server created the thread and completed the run. Reopening it then shows "Thread unavailable" until the app is force-quit.

Change

The thread screen showed the queued prompt as a stand-in while the server created the thread, and several parts of that screen (the model, queue and subagent readers) loaded the thread's details straight away instead of waiting for the creation like the main selection does. When that first request reached the server a moment before the thread existed, the client recorded the thread as deleted and stopped listening, so the stand-in never handed over to the live conversation.

On mobile, every reader of a thread's details now waits until a queued creation is confirmed by the server, so nothing asks for a thread that does not exist yet. In the shared client runtime, a "not found" result from before a thread existed is no longer remembered when the screen closes, so opening the thread again asks the server instead of showing "Thread unavailable". A real deletion is still remembered as before. Web and desktop share that client runtime code and get the reopen fix too; web's own new-thread flow already waited correctly.

Scope and approval

This fixes the bug reported in #16600. Both changes serve that one failure: the mobile guard stops the early request, and the client runtime change keeps an early miss from sticking.

Verification

New tests drive the real mobile state and client runtime subscription code through the reported order of events: a queued creation with an image attachment, a "not found" snapshot before the thread exists, the thread being created, and the run completing, then closing and reopening the thread. They fail without this change on both symptoms and pass with it. A further test covers leaving the screen right after the miss is recorded. Mobile and client runtime state tests pass, along with lint, typecheck and knip.

On an iPhone 17 Pro Max Simulator running a Release build with this change against a local server, I started a thread from the app with an image attachment, waited for the reply, opened another thread and came back. The conversation appeared as soon as the reply arrived and was still there after reopening.

Before (iPhone, stuck)	Before (reopened)	After (new thread)	After (reopened)

Recording of the create, reply, navigate away and reopen flow (MP4):

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for digging into this and for the clear write-up! The issue this PR fixes, #16600, was closed as a duplicate of #15605, and there's already an open fix for that bug in #15870, so I'm closing this one as superseded to keep the work in one place.

If your change covers something #15870 misses, like the shared client runtime no longer remembering a "not found" from before the thread existed, please share that on #15870 or #15605 so it can be folded in there.