[Java][FlightSQL][JDBC] Driver drops TLS for endpoint locations advertised by the server

When a query result has endpoints with non-empty locations, `ArrowFlightSqlClientHandler.getStreams` clones the connection's `Builder` and connects to each advertised location. The clone keeps `username`/`password`, `token` and the OAuth config, and encryption is then set from the location scheme alone:

```java
.withEncryption(endpointUri.getScheme().equals(LocationSchemes.GRPC_TLS))
```

So a location with any other scheme (`grpc+tcp://` in particular) turns encryption off for that endpoint client even when the connection was opened with `useEncryption=true`. `build()` then runs the handshake and sends the credentials over the plaintext channel to the advertised host.

The documented meaning of `useEncryption` (default `true`) is "Whether to use TLS (the default is an encrypted connection)", so a server-supplied string silently overriding it is surprising: a compromised or hostile Flight SQL server, or anything able to influence the `FlightInfo` it returns, can have the driver hand over the user's credentials in cleartext, and a passive attacker on the endpoint path can read them.

Reproduced against a handler built with `withEncryption(true)` plus a username/password, given a `FlightInfo` with one endpoint at `Location.forGrpcInsecure(...)`: the driver attempts the connection and reaches `ClientHandshakeWrapper` on the unencrypted channel instead of refusing it.

`arrow-flight-sql-jdbc-driver`, main.

从 ArrowFlightSqlClientHandler.getStreams 开始，追踪已公布的 endpoint 位置如何配置克隆的客户端；检查 ClientHandshakeWrapper 以了解观察到的握手路径。使用 withEncryption(true)、credentials 和一个不安全的 FlightInfo endpoint 重现问题，然后添加回归覆盖，证明已配置的加密要求不会被静默丢失，并且 credentials 不会通过明文发送。

由索引模型根据 Issue 内容生成。