perf(mobile): composer draft no longer re-renders the thread screen when typing#21261

Each keystroke in a thread's composer re-rendered the whole thread screen: the route, header, feed, floating controls and, on Android, the Home screen behind it.

Every keystroke replaces the composer drafts map, and four readers subscribed to the whole map: the thread composer state hook (feeding ThreadRouteContent), the selected-thread request hook (for question attachments), Home's pending tasks, and the attachment upload worker.

Now each reader subscribes to only what it shows:

• ThreadComposer reads its own draft through a per-key composerDraftAtom, so the draft text and attachments are no longer route props.
• useThreadComposerState reads only the draft's model, runtime and interaction mode (useComposerDraftSettings).
• The request hook reads the question drafts under its thread's prefix. Pending tasks read only new-task drafts. The upload worker reads only attachments and project. All three projections compare their entries by reference, so they stay equal while only text changes.
• setComposerDraftText keeps the draft's attachment array when no attachment was dropped. It used to rebuild the array on every edit, which defeated the upload worker's comparison.

Renders on the device

Pixel 9 API 36 emulator, dev client, median of 3 runs, same base (layer 9) and device. In the typing scenario, the app opens a thread, focuses the composer and types five words with adb input text, recorded with the render counter from measure-renders.mts.

The composer itself still renders on every keystroke, as it should.

On Android I typed a draft, left the thread and came back to the same draft, cleared it, opened the attachment menu, sent a turn, and queued a follow-up while it streamed. The queued message was delivered ("from queue").

Claude Opus 5.5 via Claude Code.

🤖 Generated with Claude Code