…er preliminary cancellation distributed queries

…ter preliminary cancellation distributed queries

…ter preliminary cancellation distributed queries

…ter preliminary cancellation distributed queries

Backport #93029 to 25.11: Fix leaving connection in a broken state after preliminary cancellation distributed queries

Backport #93029 to 25.12: Fix leaving connection in a broken state after preliminary cancellation distributed queries

Backport #93029 to 25.10: Fix leaving connection in a broken state after preliminary cancellation distributed queries

Backport #93029 to 25.8: Fix leaving connection in a broken state after preliminary cancellation distributed queries

The race condition causes a crash when reading from a disconnected
connection in distributed queries.

The `in` buffer:

```
(gdb) frame 1
(gdb) print this->in
$19 = {__ptr_ = 0x0, __cntrl_ = 0x0}
(gdb) print this->connected
$18 = false
```

But the same time:

```
(gdb) frame 2
    async_callback=...) at ./ci/tmp/build/./src/Client/MultiplexedConnections.cpp:398
(gdb) print this->sent_query
$15 = true
(gdb) print this->cancelled
$16 = false
(gdb) print this->active_connection_count
$17 = 1
```

Current solution will not fix the issue, it just apply a check like in
`sendCancel()`.

Related PRs:
- ClickHouse#89740
- ClickHouse#92807
- ClickHouse#93029

…TablesStatusResponse, got ProfileInfo)"

Distributed queries over hedged connections intermittently fail during connection
establishment with:

    Code: 102. UNEXPECTED_PACKET_FROM_SERVER:
    Unexpected packet from server 127.0.0.2:9000 (expected TablesStatusResponse, got ProfileInfo)

thrown from `Connection::getTablesStatus` via `ConnectionEstablisher::run`. A pooled
connection (initiator to replica) is reused while it still holds undelivered packets
(`ProfileInfo`/`EndOfStream`) that a previous, cancelled distributed query left behind, so
the table-status request reads a stale packet instead of the expected response.

This is a recurrence of the issue fixed in ClickHouse#93029 (originally reported as ClickHouse#93018). It came
back after ClickHouse#95466 added `|| was_cancelled` to the early-return guard in
`RemoteQueryExecutor::finish`, which makes `finish` skip the drain after a cancellation.

Two changes:

1. `RemoteQueryExecutor::finish`: when the query was already cancelled and its connections may
   still hold undelivered packets, disconnect them instead of leaving them to be returned to
   the pool in an out-of-sync state. We do not drain them here (the read side may already be
   torn down, which previously crashed - see ClickHouse#95466), but they must not be reused. This mirrors
   the cleanup the destructor already does, performed eagerly so it cannot be skipped if
   `finished` later becomes true through another path.

2. `ConnectionEstablisher::run`: treat `UNEXPECTED_PACKET_FROM_SERVER` like the other "the
   pooled connection turned out to be unusable" errors (NETWORK_ERROR, ATTEMPT_TO_READ_AFTER_EOF,
   ...): disconnect the entry and report a soft failure so connection establishment retries on a
   freshly established connection, instead of failing the whole distributed query. This is the
   documented design (the optimistic path does not ping a pooled connection before use and relies
   on retrying), it just did not cover a connection left out of sync.

Adds a fail point (`unexpected_packet_in_table_status_response`) and a deterministic test
(`04489_distributed_table_status_desync_recovery`) that injects the desync and verifies the
query recovers.

CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?REF=master&sha=799ffffcce85c605e19d0116ccad68955ebd784a&name_0=MasterCI&name_1=Stateless%20tests%20%28arm_binary%2C%20parallel%29
Related: ClickHouse#93018

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>