Feature request: support live DNS/source-IP verification for peer hostnames as an alternative to SAN-only allowlisting

### What would you like to be added?

## Summary

Requesting a new peer-admission option that verifies a connecting peer's source IP
against a live DNS resolution of a configured hostname, in addition to existing CA
and CN/SAN validation — similar to how PostgreSQL's `pg_hba.conf` combines
`clientcert=verify-ca` with a specific hostname entry.

## Motivation

In our deployment, the internal CA issues peer certificates using a wildcard SAN
(e.g. `*.example.com`), which is a common pattern in enterprise/internal PKI.
`--peer-cert-allowed-cn` / `--peer-cert-allowed-hostname` is configured as an
additional membership allowlist on top of CA validation.

With a wildcard SAN, any certificate issued by the trusted CA and matching the
wildcard satisfies the allowed-hostname check. This means the allowlist can't distinguish one
enrolled member from any other holder of a wildcard-SAN cert from the same CA. Once
the mTLS handshake succeeds, Raft peer identity is self-declared and not cross-validated against the certificate,
so such a peer could present itself as any known member ID.

## Proposed feature

PostgreSQL's `pg_hba.conf` handles an analogous case by combining CA validation with
a specific per-entry hostname, e.g.:

hostssl replication replicator node1.example.com clientcert=verify-ca

Here, `clientcert=verify-ca` confirms the certificate is CA-signed, and
`node1.example.com` is resolved live, per connection, and compared against the
actual source IP of the connecting client — not matched as a string/wildcard against
a SAN field. A wildcard cert doesn't help here, since the check is "does this
specific configured hostname's current DNS resolution matches where the connection is
actually coming from," not "does the SAN match a pattern."

We'd like to request that etcd's peer allowlist support the same model: alongside
(or as an alternative to) `--peer-cert-allowed-hostname` matching against SAN
content, allow configuring specific per-member hostnames (e.g. `node1.example.com`,
`node2.example.com`) that are resolved via live forward DNS lookup and compared
against the actual source IP of each incoming peer connection, on top of existing CA
validation. This would keep CA validation unchanged, but remove wildcard SANs as a
viable way to satisfy the allowlist, since admission would depend on the peer's
real, current network location rather than on certificate content alone.

### Why is this needed?

This wouldn't fully address the fact that Raft's `From` field is self-declared and
unbound to connection identity, but it would meaningfully narrow the admission gap
introduced by wildcard-SAN certificates.

Start by tracing etcd's existing peer certificate allowlist validation and the incoming peer connection's source-IP handling. Review how CA and CN/SAN checks are configured, then determine the design for per-member hostname resolution, DNS refresh timing, failure behavior, and interaction with Raft peer identity. Done means the admission model and its security tradeoffs are specified well enough to implement and test.

Written by the indexing model from the issue text.