fix(mobile): a message queued offline no longer switches the thread to a stale model#24562

Problem

On mobile, a follow-up typed while the app is offline can move the thread to a provider and model nobody picked.

When Send is pressed, useThreadComposerState stores draft.modelSelection ?? thread.modelSelection in the outbox, where thread is the app's cached copy. Delivery always sends the stored model, so the server treats it as a choice and switches the thread with a context handoff. If another client moved the thread while the phone was away, the cached model is stale. The outbox also drains right after reconnecting, before the fresh shell snapshot arrives, so the cache can't catch up first. In the case that led to this fix, the queued message was dispatched 12 ms after the app requested the fresh snapshot.

Steps to reproduce:

1. On the mobile app, open a thread running on model A.
2. Take the phone offline.
3. On desktop or web, switch the thread to model B (another provider) and send a message.
4. On the phone, type a follow-up without touching the model picker and press Send. It is queued.
5. Bring the phone back online.

Expected: the follow-up runs on model B. Actual: the server switches the thread back to model A.

Change

• The send path queues a model only when the draft holds a pick. Delivery sends modelSelection only for a pick; otherwise the server uses the thread's own model (command.modelSelection ?? thread.modelSelection).
• Without a pick, delivery skips the client-side isModelSelectionUnavailable check. That check would test the cached model, which can be stale, and the server validates the thread's own model itself.
• Outbox entries written by older builds carry the cached model on every follow-up. New writes mark a stored model with modelPicked: true, and reading an unmarked follow-up drops its model, so an outbox file or signed-out archive from an older build can't replay a stale model. Thread-creation entries keep theirs. The field is optional, so writes stay at schema version 3 as the existing v4 note requires. A follow-up stored by an older build that did hold a real pick loses it and runs on the thread's current model.

Scope and approval

No prior issue: I searched and found none for this. It qualifies as a small, focused fix for an obvious bug: the outbox replays a model the user never chose, and the change is three mobile source files (about 30 lines) plus tests. No contract, server or UI change. #13995 (queued messages not sent while Connected) is a different problem.

Verification

New cases in the existing test files:

• thread-task-permissions.test.ts: a follow-up queued with no pick stores no model.
• use-thread-outbox-drain.permissions.test.ts: a follow-up without a pick is delivered with no model; it is delivered even when the cached model looks unavailable; a pick is still sent.
• thread-outbox.test.ts: an unmarked follow-up from an older build drops its model; a thread creation keeps it; a marked pick round-trips.

vp test run apps/mobile/src/state/thread-outbox.test.ts apps/mobile/src/state/thread-task-permissions.test.ts apps/mobile/src/state/use-thread-outbox-drain.permissions.test.ts: 60 pass. With the three source files restored from main, 4 of the new cases fail (the pick and creation cases are guards and pass on both). vp run check:changed upstream/main passes (format, lint, knip, typecheck, tests).

Not checked: I did not run this build on a device or simulator. The reproduction comes from server logs of a real occurrence with the iOS app, not from a rerun with this change.

Implementation: Claude Opus 5.5 via Claude Code in T3 Code.