fix(responses): avoid replaying uncertain typed sends on reconnect (#4011)

A typed Responses WebSocket command could reach the server and then
raise locally. Reconnecting replayed that command, potentially creating
a duplicate response. The same problem occurred if sending a queued
command failed or was cancelled midway through a flush.

Queue only commands that have not been attempted. On a failed Responses
flush, discard the attempted item and retain the unsent tail in order
with its original byte limits. Keep typed sends on their existing
transport path so applications that customize `send_raw()` do not
unexpectedly intercept typed sends. This covers stable/beta and
sync/async; Realtime retains its existing queue policy.

Validation on this change:
- 294 affected Responses session, auth, preconnect, URL, queue and
Realtime recovery tests pass with both Pydantic v1 and v2.
- Extended the real WebSocket no-replay regression with a customized
raw-send policy: all four typed variants fail before the compatibility
fix and pass afterward; all four raw controls pass.
- Ruff, formatting and `git diff --check` pass.
- Local tests used the committed dependencies (`uv --frozen`): the local
uv is newer than the uv 0.12.5 pinned in CI. Hosted checks must still
pass on the published commit.