Restrict failed-stream trimming to the first fallback payload

When stream.isFailed is true, this branch always slices payload.text by stream.streamedLength, but isFailed remains true for the rest of the turn. After an overflowed first segment, later onPartialReply calls (for post-tool segments) still set streamReceivedTokens = true even though stream.update() is a no-op on a finalized stream, so preparePayload re-enters this block and drops/truncates unrelated later segments (e.g., second segment becomes undefined if shorter than the prior streamed prefix). This turns a dedup fix into content loss whenever a long first segment is followed by additional text segments.

Useful? React with 👍 / 👎.

streamedLength may be stale at read time

lastStreamedText is updated inside the async pushStreamChunk callback, which runs as part of loop.waitForInFlight() inside finalize(). Because finalize() is kicked off with void (not awaited) from update(), and finalize()'s idempotency guard sets this.finalized = true synchronously before the await, a subsequent stream.finalize() call from the controller returns immediately without waiting for the first call to finish. If preparePayload reads stream.streamedLength before waitForInFlight() resolves, it sees a stale lastStreamedText and the suffix trim will be incorrect — potentially leaving some already-streamed chars in the fallback payload.

In practice the window is narrow (many await points exist between the failing update() call and preparePayload being invoked), but the correctness guarantee is absent. One way to close it: store lastStreamedText as a snapshot on streamFailed being set (since at that moment no new successful pushes can start), rather than lazily reading from the field that a still-running in-flight push may update.

This is a comment left during a code review.
Path: extensions/msteams/src/streaming-message.ts
Line: 223-225

Comment:
**`streamedLength` may be stale at read time**

`lastStreamedText` is updated inside the async `pushStreamChunk` callback, which runs as part of `loop.waitForInFlight()` inside `finalize()`. Because `finalize()` is kicked off with `void` (not awaited) from `update()`, and `finalize()`'s idempotency guard sets `this.finalized = true` synchronously before the `await`, a subsequent `stream.finalize()` call from the controller returns immediately without waiting for the first call to finish. If `preparePayload` reads `stream.streamedLength` before `waitForInFlight()` resolves, it sees a stale `lastStreamedText` and the suffix trim will be incorrect — potentially leaving some already-streamed chars in the fallback payload.

In practice the window is narrow (many `await` points exist between the failing `update()` call and `preparePayload` being invoked), but the correctness guarantee is absent. One way to close it: store `lastStreamedText` as a snapshot on `streamFailed` being set (since at that moment no new successful pushes can start), rather than lazily reading from the field that a still-running in-flight push may update.

How can I resolve this? If you propose a fix, please make it concise.

In the stream.isFailed fallback path we reset streamReceivedTokens, but we don’t stop/finalize the underlying TeamsHttpStream. Since TeamsHttpStream.update() doesn’t short-circuit on streamFailed and createDraftStreamLoop will keep retrying when pushStreamChunk() returns false, the stream can continue attempting POSTs (and potentially deliver additional chunks) until markDispatchIdle() calls finalize(). Consider triggering a best-effort stream.finalize() (or otherwise stopping the loop) as soon as failure is detected here to avoid ongoing stream retries while fallback delivery is happening.