fix(web): follow the thread's model after another client changes it

[alizenhom]

Fixes #10684.

After a send, the web composer kept its stored model selection for that thread. That selection wins over the server thread's model for both the picker and the next send, so when another client switched the thread to a different model, desktop kept showing the old one and silently wrote it back on the next message.

Every explicit model pick on a thread draft now gets its own id. A send captures that id, and once the turn starts the composer releases the selection only while the draft still holds that id. A pick made while the send was in flight, including a same-value re-pick, has a different id and stays. With the override gone, the composer follows thread.modelSelection, so a change from another client shows through and the next send no longer reverts it.

A draft session is only marked sent, because its local placeholder thread shows the project default until the server thread arrives. The marker is persisted, and promotion drops the selection instead of moving it onto the server thread. Draft storage moves to version 10; the migration also strips never-picked seeds from server-thread drafts, which fixes threads created before this change without one more silent reversal.

Known limitation: explicit picks persisted before this change carry no marker, so a stale one is released only after the next send from this client. Seeded ones are covered by the migration. Mobile has its own fix in #10205; no wire, server, or mobile changes here.

Verification

Two paired browser tabs against one isolated dev server, Claude provider, same thread. The thread's model_selection_json was read from the projection table after each step.

Step	Before (main)	After (this branch)
Tab 1 picks Sonnet 5, sends	thread: sonnet-5	thread: sonnet-5
Tab 2 picks Opus 5, sends	thread: opus-5, tab 1 still shows Sonnet 5	thread: opus-5, tab 1 shows Opus 5
Tab 1 sends again	thread reverts to sonnet-5	thread stays opus-5
Tab 1 picks Fable 5.1 without sending, tab 2 switches to Sonnet 5 and sends	not run	thread: sonnet-5, tab 1 keeps its unsent Fable 5.1 pick

Recordings of tab 1; the second tab acts off-screen.

Before, on main: tab 1 keeps showing Sonnet 5 after the remote switch to Opus 5, and its next send reverts the thread.

before-stale-model.mp4

After, on this branch: tab 1 switches to Opus 5 when the remote change lands, and its next send leaves the thread on Opus 5.

after-follows-remote-model.mp4

Reloading both tabs between the runs migrated their v9 storage to v10 in place.

Tests: composer draft store suite (115 tests, 9 new) covering the pick id rules, release on server threads, a newer pick surviving the in-flight window, the draft-session hold and promotion drop, and the persisted marker across a reload. Model selection, thread action, and ChatView logic suites pass (169 tests). Web typecheck, lint on the changed files, and formatting pass.

Prepared with Claude Fable 5.1 in Claude Code.

🤖 Generated with Claude Code

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This targeted fix changes existing send behavior by clearing or carrying model overrides across asynchronous sends, reloads, and draft promotion. Its persistent state migration and multiple lifecycle paths make the runtime impact broader than a simple isolated correction.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}