3.x: fix synchronous connection failures in request retry internals #941

Parent issue: #939

Scope

Fix request-retry paths where synchronous connection failures can bypass the intended callback-based retry handling.

This is separate from the keyspace setup pool fix and focuses on RequestHandler behavior around internal retry machinery.

Proposed Changes

• Add a narrow guard around pool.borrowConnection(...) in RequestHandler.SpeculativeExecution.query() for connection/pool setup failures that can still be thrown synchronously. ConnectionException and BusyConnectionException should be handled like the existing callback failure path and should move to the next host where possible.
• Fix the UNPREPARED recovery branch so synchronous failures from the internal PREPARE write do not become final request failures. The original user query has not been executed yet, so a connection failure while preparing should retry another host.
• Review current-host retry re-entry (retry(true) -> query(currentHost)) so synchronous connection failures do not become final exceptions while other hosts remain available.

Acceptance Criteria

• Synchronous ConnectionException from RequestHandler.query() connection setup is recorded for the current host and the request proceeds to the next host when possible.
• Synchronous ConnectionException / BusyConnectionException during UNPREPARED internal PREPARE write retries another host instead of failing final.
• The implementation does not retry validation/programmer errors as transport failures.
• Tests cover next-host retry for synchronous connection setup failure and UNPREPARED internal prepare write failure.