Bound user cancellation by Cancellation Timeout while prepended responses are outstanding - #6663

Fixes #6662

When the user's token fires while a prepended query (DISCARD ALL on a pooled connection) is still unanswered, PerformImmediateUserCancellation defers the cancellation and returns without arming a deadline. If the server never answers, the token has no effect until Command Timeout.

What this changes:

• When the cancellation is deferred, the read deadline is set to Cancellation Timeout right away. With -1 it is 1 ms, not zero, because a zero Socket.ReceiveTimeout disables the timeout for sync reads. With 0 nothing changes.
• When that deadline fires while the deferred cancellation is pending and prepended responses are still unread, the read buffer does not send a PostgreSQL cancel request (that could cancel the prepended query, Received backend message CommandComplete while expecting BindCompleteMessage. Please file a bug. #4906). The connector breaks with OperationCanceledException instead.
• If the prepended responses arrive in time, PerformDelayedUserCancellation runs as before and re-arms its own Cancellation Timeout. Nothing blocks, so Npgsql 7.0.2 blocks threads NpgsqlConnector.PerformUserCancellation causing connection pool exhaustion #5032 does not come back.

Limitation: a synchronous receive that is already blocked isn't interrupted, because a ReceiveTimeout change doesn't affect it. That read still ends at Command Timeout. It then breaks without sending a cancel request, and the sync reads after it are bounded by Cancellation Timeout. Main has the same limit for sync hard cancellation of non-prepended commands. Interrupting the blocked receive is #5070.

How I tested it:

• New CommandTests.Cancel_async_with_prepended_query_server_unresponsive (PgPostmasterMock, Command Timeout=30, Cancellation Timeout=1000). It fails on main after 31 s and passes with this change in about 1 s. It also checks that no cancel request reaches the server.
• New CommandTests.Cancel_sync_with_prepended_query_server_unresponsive(1000, -1): sync Cancel(). The server sends part of the DISCARD ALL response and then stalls. It takes 30–31 s on main and about 1 s with this change. It also checks that no cancel request is sent.
• These pass locally against PostgreSQL 17: CommandTests, PoolTests and the tests matching Cancel (117 passed, 3 skipped), and the tests matching Timeout/Prepend (12 passed, 1 skipped).
• Batched_small_then_big_statements_do_not_deadlock_in_sync_io hangs in my local setup (Windows + Docker), and it hangs on unmodified main too, so I excluded it.
• Freezing-proxy repro from the issue: with defaults and the token canceled at 3 s, the command now returns at 5.0 s instead of 60 s. The no-token Command Timeout path is unchanged.