[Subtask] M3: Public TLS API on the client builders, documentation, and e2e

### Describe the subtask

The commitment milestone. M2 built the capability behind an internal boundary;
this subtask makes it public API — the step we can't walk back — and makes it
discoverable, so a user finds it in the docs rather than by reading source.
This is also where end-to-end coverage lands, because the path e2e must
exercise (server config to public builder to handshake to API call) only
exists once this does.

## Deliverable

- **The surface:** TLS configuration exposed on the `GravitinoClient` and
`GravitinoAdminClient` builders, exactly as specified in
`design-docs/gravitino-client-tls.md`. Nothing internal leaks into a public
signature.
- **The docs:** `docs/security/how-to-use-https.md` currently instructs users to
import server certificates into the JVM-wide truststore — the exact workaround
this epic eliminates. Its Java example switches to the new API.
`docs/how-to-use-gravitino-client.md` gains a TLS configuration section
covering the private-CA and mutual-TLS journeys.
- **End-to-end proof:** an integration test that starts a real Gravitino server
with `gravitino.server.webserver.enableHttps=true` (and a client-auth
variant) and performs an actual metalake operation through
`GravitinoClient.builder(...)` with the new TLS API — closing out the e2e
testing request from #10975 review. Two scenarios (HTTPS, mTLS); the full
handshake matrix already lives in M1/M2 where it's cheap.

## Acceptance criteria

- [ ] Builder surface matches the design doc exactly; deviations go back
through the doc
- [ ] No internal type appears in any public signature
- [ ] Javadoc on every new public method
- [ ] At least one test constructs the client through
`GravitinoClient.builder(...)` against a TLS server — not only through
`HTTPClient`
- [ ] The e2e IT above passes in CI, consuming fixtures and server setup from
M1's test artifacts
- [ ] The HTTPS doc's Java example no longer touches the JVM truststore
- [ ] The client doc covers TLS configuration with runnable examples
- [ ] The PR is marked as a user-facing change
- [ ] A client that configures no TLS behaves exactly as today

Depends on: M0 (the shape), M2 (the capability).
Blocks: M4 (convenience helpers), M5 (protocol/cipher configuration and
system-truststore mTLS).

### Parent issue

#9836

Read design-docs/gravitino-client-tls.md first, then inspect the GravitinoClient and GravitinoAdminClient builders and M1/M2 test fixtures. Update docs/security/how-to-use-https.md and docs/how-to-use-gravitino-client.md, and locate the existing integration-test setup for the HTTPS and mTLS scenarios. Done means the public API matches the design, both end-to-end paths pass through the builders, documentation has runnable examples, and no-TLS behavior is unchanged.

Written by the indexing model from the issue text.