[Bug]: stream retries re-send already-billed requests and retry deterministic 4xx

[1688mengdie]

Problem

execute_sse_request retries with the same request_body in two cases that
should be terminal:

1. A TTFT (time-to-first-token) timeout re-sends an already-sent request. The
   request body is sent to the server before the first-token wait begins, so
   the retry re-sends an already-billed request (double-billing for the same
   logical turn).
2. A deterministic 4xx (for example 400) is retried. A deterministic client
   error fails identically on every attempt, so the retry only burns the
   request budget/credits and adds latency.

Root cause

The retry decision in execute_sse_request does not distinguish terminal from
transient outcomes. The TTFT branch continues using the same request body,
and the non-2xx branch retries every status, including 400. The
SEND_MESSAGE_STREAM_ATTEMPTS counter is amplified by these re-sends.

Repro

1. For TTFT: mock a server that never completes a response, inject a small
   ttft_timeout, and observe execute_sse_request re-send the same body
   across attempts.
2. For 4xx: mock a server that returns 400 and observe the fixture is called
   more than once (the old bad_requests_then_success fixture even reports
   success when a later attempt returns 200).

Impact

Billing is charged twice for the same logical turn on TTFT timeout, and
deterministic client errors waste credits/latency across up to
SEND_MESSAGE_STREAM_ATTEMPTS re-sends.

[kev1n77]

感谢反馈，这里需要区分两个问题。
确定性 4xx 错误的重复请求已在 #2690 跟踪，并已提交修复 PR #2813 。两者涉及不同层级的重试，因此后续应结合该 PR 核对实际调用链，避免仅修复一层后仍由另一层重发。若存在该 PR 未覆盖的底层直接调用场景，欢迎补充具体复现。
TTFT 超时后是否重试属于另一项策略问题。请求已发送并不能证明供应商已经计费，目前也没有实际重复扣费的证据。首 token 超时可能是暂时性故障，直接禁止重试会损失恢复能力，因此暂不采纳“一旦 TTFT 超时就终止”的方案。
确定性错误的修复统一在 #2690 对应 PR 中跟踪；TTFT 部分如有具体供应商行为、重复处理或计费证据，可另行补充讨论。