Fix ConnectionErrorRetryTimeout to act as a hard deadline during connection attempts

[rhysparry]

Summary

• ConnectionErrorRetryTimeout was only checked at the start of each retry loop iteration in SecureListeningClient, so a single blocked connection attempt (slow TCP connect or frozen SSL handshake) could exceed the deadline by up to one full per-attempt timeout before the loop could exit.
• Adds a CancellationTokenSource armed at ConnectionErrorRetryTimeout whose token is passed into AcquireConnectionAsync, propagating through both ConnectWithTimeoutAsync and AuthenticateAsClientEnforcingTimeout. This makes the deadline a true hard ceiling on each individual attempt.
• Deadline-triggered OperationCanceledException is converted to TimeoutException in the catch block so HandleError surfaces it as HalibutClientException rather than re-throwing as OperationCanceledException.
• Includes a regression test using a paused port forwarder (TCP connects immediately but data is frozen, causing SSL handshake to block until stream timeout). With ConnectionErrorRetryTimeout=3s and per-attempt stream timeout of 8s, the test verifies the call fails in under 6s.

Implications for existing users

Production defaults (ConnectionErrorRetryTimeout=5min, TcpClientConnectTimeout=60s, TcpClientTimeout=10min): no practical change. Retries complete (or exhaust RetryCountLimit) long before the 5-minute deadline fires.

Short ConnectionErrorRetryTimeout with long per-attempt timeouts: behaviour visibly changes. Previously a single stuck TCP connect or SSL handshake could outlast the deadline by up to TcpClientConnectTimeout or TcpClientTimeout.receive. Now the attempt is interrupted at the deadline. This is the intended semantics of the setting.

Exception type: the deadline case previously accidentally produced OperationCanceledException (via HandleError's switch case). It now produces HalibutClientException, which is the correct type for RPC timeout errors in Halibut.

Background TCP socket: when the deadline fires inside ConnectWithTimeoutAsync, the underlying ConnectAsync task is orphaned and the socket is force-closed via DisposeClient() — the same behaviour as when TcpClientConnectTimeout fires normally.

net48 SSL handshake: AuthenticateAsClientAsync on .NET Framework ignores cancellation tokens (noted in TcpConnectionFactory.cs with a // TODO: ASYNC ME UP! comment). The deadline CTS can still interrupt the TCP connect phase, but has no effect inside the SSL handshake on net48; the stream's ReceiveTimeout still controls that phase.

Test plan

• New test ConnectionErrorRetryTimeout_IsAHardDeadlineEvenWhenIndividualAttemptsBlockLonger confirmed failing before fix (~10s, wrong exception type) and passing after fix (~3.7s, HalibutClientException)
• All 5 ListeningConnectRetryFixture tests pass (including existing timeout and retry-count tests)

🤖 Generated with Claude Code

[rhysparry]

We want to avoid this behavioral change.