Dead sessions are reused with auto-reconnect off; frame-too-large rejection desynchronizes the connection

Two related liveness/robustness issues:

1. **`Session::is_open()` is `connection.is_some()`, not socket state.** With `enable_auto_reconnect = false`, a session whose connection died (silent peer, FIN lost, etc.) is reused indefinitely under load: the pool's acquire-side eviction loop (`entry.session.is_open()`) keeps handing it out, every RPC on it blocks or fails, and nothing ever discards it. A transport-level failure should mark the connection broken so `is_open()` turns false and the pool discards/replaces the session.
2. **Frame-too-large rejection desynchronizes the connection.** `TFramedReadTransport` (thrift 0.23) rejects a frame above its default 16,384,000-byte cap *before draining the body*, leaving the connection desynchronized; `fetch_results` does not go through `with_retry`, so the desynchronized connection is then reused. Go and C# use the same cap, so the cap itself is not Rust-specific — the fix worth having is that a transport-level failure (including this one) marks the session broken, so the pool evicts it and auto-reconnect (when enabled) replaces it. (`execute_query_raw` deliberately excludes the result-set-pinned `fetch_results` from retry; see spec gotcha #13.)

Trace Session::is_open(), the pool's acquire-side eviction loop, TFramedReadTransport, fetch_results, with_retry, and execute_query_raw. Start by reproducing or following the transport-failure path, then verify that failures mark the session broken, the pool evicts it, and auto-reconnect replaces it when enabled without adding retry behavior to fetch_results.

Vom Indexierungsmodell aus dem Issue-Text verfasst.