feat(sql): follow adaptive streaming and polling responses (#4664)

SQL execution now starts with one Flight call. The server can stream
rows immediately or return a polling continuation, which the SDK follows
through the existing query handle and reader APIs. The same behavior
applies with and without parameters.

Both initial transports share direct-stream lifecycle handling. Handoffs
are explicitly negotiated; existing servers can continue returning
ordinary streams. Add coverage for streaming, deferred results,
cancellation, malformed decisions, and legacy responses.

```mermaid
flowchart TD
    A[execute_query or execute_query_async] --> B{Parameters supplied?}
    B -->|No| C[DoGet: SQL command ticket]
    B -->|Yes| D[DoExchange: SQL and Arrow parameter row]
    C --> E[Server chooses execution path]
    D --> E
    E -->|Stream| F[Initial response: streaming decision and Arrow batches]
    E -->|Defer| G[Initial response: PollInfo continuation]
    G --> H[SDK follows PollFlightInfo]
    H -->|Still running| H
    H -->|Result endpoints available| I[SDK fetches tickets with DoGet]
    F --> J[Query reader yields Arrow batches]
    I --> J
```

`execute_query` opens the reader; `execute_query_async` returns its
query handle. The caller does not select the transport or execution
path.

docs/web/basics/sql.mdx

@@ -82,6 +82,8 @@ In application code, load credentials from environment variables or a secrets
 manager. The [connection guide](/basics/connect#enterprise) shows that setup.
 
 `execute_query()` returns a blocking Arrow reader when results start arriving.
+The server can stream rows on the first call or return result tickets that the
+SDK follows automatically, with the same behavior for parameterized queries.
 The example uses `read_all()` to collect the small result in memory. For larger
 results, consume the reader in batches. To submit a query and check its status
 separately, use `execute_query_async()`. See [Queries](/basics/query) for query