[mgravell]

Fixes #3283

Causes (all three in the report confirmed)

1. The drain hands out raw or null exceptions. RecordConnectionFailed builds its detailed RedisConnectionException only for the bridge's current connection and only on the first report. A repeat report (write path and read loop both reporting), or one against a connection the bridge has already replaced, drains _writtenAwaitingResponse with the raw inner exception, or with null, which TaskResultBox turns into TaskCanceledException. Every EOF path in the read loop reports with no exception.
2. A write failure races the drain. The write-lock catch fails the message with a proper exception, then reports the connection, which drains the same still-queued message again with the raw exception. Last write wins, hence the RESPite writer's InvalidOperationException in the reported stack trace.
3. Bridge refusals use Cancel(). FailDueToNoConnection, TimedOutBeforeWrite and the fail-fast bin complete the message as cancelled. ExecuteAsyncImpl then tries to fault the task with the real exception, but the box's continuation is queued to the thread pool and sometimes gets there first. A batch has no such translation at all.

Changes

• RecordConnectionFailed: if the exception chosen for the drain is not already a RedisException, wrap it in a RedisConnectionException carrying the failure type and the original as InnerException.
• PhysicalBridge: the three refusal paths set the same exception the caller path would have built (ExceptionFactory.NoConnectionAvailable / Timeout) instead of cancelling. Message.Cancel itself is untouched; transactions rely on it for aborted conditions.
• ConnectionFailureExceptionTests: the drain with null and with an IOException inner, on a bridge-less dummy connection (exactly the non-current path), plus the no-connection refusal observed at the message's own task rather than through the caller's translation.

Verification

Check	Result
Reporter's repro verbatim, 90 s, before	884 TaskCanceledException, 415 InvalidOperationException
Same repro, 90 s, after	only ok and RedisConnectionException
New tests + write-failure, backlog, batch, transaction tests	469 passed
Full net10.0 suite on the docker topology	6665 passed, 161 skipped, 1 failed (FailoverTests.SubscriptionsSurvivePrimarySwitchAsync, pre-existing flake, same rate on main)
dotnet build Build.csproj -c Release /p:CI=true	0 warnings, 0 errors

Note: TimedOutBeforeWrite now builds the full timeout exception in the bridge while the single-command caller still builds its own from the result, so that path allocates twice. It only runs when the write lock cannot be taken within the timeout; left as is rather than restructure the caller.

Related: #3282 (#3286), the batch hang from the same report series.