[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.

Start in ArrowFlightSqlClientHandler.getStreams and trace how advertised endpoint locations configure cloned clients; inspect ClientHandshakeWrapper for the observed handshake path. Reproduce with withEncryption(true), credentials, and an insecure FlightInfo endpoint, then add regression coverage showing that the configured encryption requirement is not silently lost and that credentials are not sent over plaintext.

Written by the indexing model from the issue text.