[fix][cli] PIP-478: client.conf tlsEnableHostnameVerification is silently ignored by pulsar-admin

### Motivation

`conf/client.conf` is read by both `bin/pulsar-client` and `bin/pulsar-admin`. It ships the key

```properties
# Whether the server hostname is verified ... Enabled by default since Pulsar 5.0 (PIP-478).
tlsEnableHostnameVerification=true
```

`bin/pulsar-client` honours it — `PulsarClientTool.applyTlsPolicy` reads
`properties.getProperty("tlsEnableHostnameVerification")` by that literal name.

`bin/pulsar-admin` does not. The backing field is named differently:

```java
// ClientConfigurationData
private boolean tlsHostnameVerificationEnable = true;
```

The `@Schema(name = "tlsHostnameVerificationEnable")` on it is Swagger metadata, not a Jackson alias —
there is no `@JsonAlias`/`@JsonProperty` in the class. `PulsarAdminTool.createAdminBuilderFromProperties`
copies every `client.conf` property into a map and calls `PulsarAdmin.builder().loadConf(conf)`, and
`ClientConfigurationData` carries `@JsonIgnoreProperties(ignoreUnknown = true)` — so the key is dropped
without a word.

The CLI flag cannot rescue it from the conf file either: `PulsarAdminTool`'s
`--tls-enable-hostname-verification` option has no `descriptionKey`, so picocli's
`PropertiesDefaultProvider` looks up `tls-enable-hostname-verification`, not the conf key, and
`PulsarAdminSupplier` only applies the flag when it was actually passed.

### What makes this new

Before PIP-478 the shipped `conf/client.conf` had `tlsEnableHostnameVerification=false` and the field
default was also `false`, so the name mismatch was a no-op. PIP-478 flipped both to `true`
(secure-by-default). The key is now the documented escape hatch for that flip — and it works on only one
of the two CLIs that read the file.

### Impact

An operator upgrading to 5.0 whose broker certificate has no matching SAN sees `pulsar-admin` start
failing the handshake, reads the shipped `client.conf`, sets `tlsEnableHostnameVerification=false`, and
`pulsar-admin` keeps failing while `pulsar-client` starts working — with no diagnostic pointing at the
ignored key.

### Suggested fix

Either give `PulsarAdminTool`'s option `descriptionKey = "tlsEnableHostnameVerification"`, or add
`@JsonAlias("tlsEnableHostnameVerification")` to `ClientConfigurationData.tlsHostnameVerificationEnable`.
Add a test that loads the shipped `conf/client.conf` through `PulsarAdminTool` and asserts the resulting
`ClientConfigurationData`.

---

Found in a final-state review of the PIP-478 series (#26321). Not a blocker for the stack — filed
separately so it can be fixed on its own.