In Coordination::ZooKeeper::sendThread, after a request is popped from the
queue the local RequestInfo is the sole owner of its callback until the request
is inserted into operations (from which receiveEvent()/finalize() later satisfy
it). Async callers such as ZooKeeper::asyncTryExistsNoThrow capture a
shared_ptr<std::promise<...>> in that callback and hand the std::future to a
waiting caller before the request is processed.

If anything in the pop->insert window throws (the OpenTelemetry span finalize,
addRootPath, or the operations map insert, all of which can allocate and throw
under memory pressure), the local RequestInfo is destroyed while unwinding and
the callback never runs. The captured std::promise is then destroyed unsatisfied,
so the waiter's future.get() observes a std::future_error (broken promise). That
future_error is a std::logic_error, which the server reports as a LOGICAL_ERROR
and aborts on (see PR ClickHouse#51907). This matches the reported crash (STID 2508-34fb,
ZooKeeper-client variant): ~promise<ExistsResponse> running from sendThread's
teardown.

Arm a SCOPE_EXIT guard over that window: if the request is dropped before its
callback ownership transfers to operations, satisfy the callback with an error
response (ZCONNECTIONLOSS if it was probably sent, otherwise ZSESSIONEXPIRED)
instead of abandoning the promise. This mirrors how finalize() drains
outstanding operations and the already-merged sibling fixes for the same error
class (TestKeeper, PR ClickHouse#73570; the thread-pool callback runner, PR ClickHouse#107383). The
fix is at the send layer, so it covers every async request type uniformly.

Add a unit test reproducing the window contract: without the guard the future
carries a broken-promise future_error; with the guard it carries a normal
ZSESSIONEXPIRED response and nothing aborts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>