Unsent composer drafts disappear when switching threads in the real App #921

Priority: P1. Reproduced/reviewed at commit 6c7a6fbe on 2026-09-05.

Switching from thread A to B and back silently loses A's unsent prompt.

Reproduction

1. Open a thread in the app and type a prompt without sending it.
2. Select another thread in the sidebar.
3. Return to the first thread.
4. The composer is empty.

Confirmed by mounting the real App with createFakeCoder and navigating A → B → A. This is not merely a Composer-only test.

Cause

App gates visibleDetail to null while the new selection's detail is fetched. ThreadView's no-detail branch omits Composer, unmounting it. Composer keeps draftsRef, attachmentsByThread and pasteCardsByThread in component-local memory, so the draft map is discarded. Existing test/composer.test.tsx:475 assumes one continuously mounted Composer and misses the real lifecycle. Related to closed #12, but the current symptom is lost drafts rather than drafts leaking between threads.

Acceptance

• An unsent prompt survives A → B → A through the real App, including uncached detail loads.
• Pending attachments and paste cards remain associated with their source thread.
• Switching to another main view and back preserves unsent input too.
• Preserve the stale-detail protection: never show A's transcript under B's selection.
• Add an App-level regression check; a Composer-only threadId swap is insufficient.

Source: src/App.tsx#L933.

Requested disposition: separate Planboard issue, plan:todo. Scope is the concrete defect above.