Investigate late submit/follow-up results crossing a conversation switch

[santoshkumarradha]

Concern to reproduce

During the independent lifecycle review of #1649, a separate pre-existing conversation-ownership risk was identified in submittedMsg / followMsg delivery. This is a source-level finding, not yet a reproduced user-visible failure.

A submit or follow-up already sent from conversation A may return after the user switches to B. app.Update forwards the result to adopt / queueFollow without checking the originating conversation generation. The new hostCall.generation bookkeeping in the #1649 candidate protects pending-call accounting; it does not route the returned stream. The unconditional result admission exists in the pre-fix base 9a2c7cdd5 as well.

This differs from #1649's duplicate replay and from the deferred, not-yet-issued sends already covered by its switch/return regression. Do not treat that regression as proof of this separate path.

Reproduction to establish

1. Open conversation A and hold its Submit or FollowUp response after the request is issued.
2. Switch to an unrelated conversation B before that response reaches the UI.
3. Release the response and stream A's answer.
4. Check that B acquires neither A's user line, answer, stream, nor follow-up queue; return to A and verify its accepted work remains reachable.

Use a deterministic delayed-response regression first, then ordinary recorded use if confirmed. Exercise both an idle B and a B already streaming.

Relevant code and expected behavior

• internal/tui3/app.go: submittedMsg dispatch and adopt.
• internal/tui3/followup.go: followMsg and queueFollow.
• Conversation switching and ownership: detach.go, offloop.go.

An accepted result must stay attached to the conversation that issued it. No text-based deduplication, lost accepted work, or silent delivery into another chat.

Status: triage pending. No fix or runtime reproduction claimed. This is tracked separately from the bounded duplicate-reply repair in #1632.