readiness-check should derive client authentication from the local server configuration

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.

### Description

The `readiness-check.sh` script runs `org.apache.fluss.server.tools.ClusterHealthReadinessCheck` against the local tablet server's client listener.

The CLI authenticates as a regular Fluss client. When no authentication configuration is supplied, it connects with unauthenticated PLAINTEXT. The only way to supply authentication today is the `READINESS_HEALTH_CHECK_AUTH` environment variable (or the `--healthCheckAuth` flag): semicolon-separated `key:value` pairs that are copied verbatim into the client `Configuration`.

### Proposal

The CLI ships inside the `fluss-server` jar and always runs inside the server pod, next to `$FLUSS_HOME/conf/server.yaml`. That file already contains everything the probe needs, including `bind.listeners` (appended by the pod start command) and the SASL credentials the server itself accepts. Let the CLI read it and configure its own client side.

### Willingness to contribute

- [x] I'm willing to submit a PR!

Start with readiness-check.sh and org.apache.fluss.server.tools.ClusterHealthReadinessCheck, then inspect the local server.yaml configuration used in the server pod. Trace how bind.listeners and SASL credentials are represented and how READINESS_HEALTH_CHECK_AUTH and --healthCheckAuth reach the client Configuration. Done means the readiness check derives client authentication from the local configuration without requiring those overrides.

Written by the indexing model from the issue text.