Discard incomplete streaming replies

[mikemikimike]

Fixes #1467

Issue: #1467

Streams that end without a finish reason or [DONE] marker are discarded and retried, so partial replies are not retained in conversation history. Either explicit completion signal remains sufficient.

Tests: go test -count=1 -p 1 -timeout 15m ./internal/provider; go test -count=1 -run 'TestATruncatedProviderReplyIsNotSettledByTheSession|TestAnIncompleteReplyIsAskedAgainWithoutKeepingItsText|TestRepeatedIncompleteRepliesSayWhatWasDropped' ./internal/session; go test ./internal/manual/; go test -run Manual ./internal/tui3/ ./internal/session/.

[CLAassistant]

All committers have signed the CLA.

[santoshkumarradha]

Hey, thanks for the PR. Could you sign the CLA when you get a chance so we can review it?

[AbirAbbas]

Thanks for this one, it's a real fix. Testing it end to end turned up two gaps, so I pushed a commit for each:

• The give-up path kept what it said it dropped. When the last retry was also cut, the turn fell through to the generic failure path, which saves the streamed text. The person was told "the partial reply was dropped" while transcript.jsonl still had it. It's now withdrawn from both the transcript and the screen; other mid-stream failures still keep their text.
• The Codex login road could never trip the guard. Its Responses translator wrote [DONE] after any clean end of the upstream stream, even without response.completed, so a truncated answer looked complete. [DONE] now only follows a terminal event, and a max_output_tokens stop still ends as a normal length-limited answer.

Checked with the real binary against a local server that cuts every reply: it retries, exits saying the partial reply was dropped, and the transcript has no trace of it. Tests for both fail without the fixes.