Prevent a joining PD member from publishing a client URL already used by another member

## Bug Report

### Problem

A new PD member can join with a unique peer URL while publishing an `advertise-client-urls` value already used by an existing member.

The problematic combination is:

- unique `--advertise-peer-urls`
- duplicate `--advertise-client-urls`
- `--join` points to a cluster Service URL instead of the duplicated per-Pod client URL

The existing self-join check does not trigger because the join URL and advertised client URL are different strings, and etcd accepts the unique peer URL. The resulting member list contains two logical members with the same client URL.

### Impact

The duplicate client URL corrupts membership and health semantics. After the orphan Pod was deleted, its member remained and still appeared healthy because its client URL routed to the healthy original PD.

In a reproduced 4-member membership with the orphan member left behind, isolating one normal PD left only 2/4 raft members available. PD APIs failed, control-plane SQL returned `context deadline exceeded`, and writes timed out or returned `PD server timeout`. A clean 3-member cluster tolerated the same single-PD isolation.

### Expected behavior / possible improvement

PD should reject or explicitly quarantine a joining member whose advertised client URL is already owned by another live member.

Health reporting should also verify the responding member identity instead of treating a successful response from a duplicated URL as proof that the intended member is healthy.

Start by tracing the member-join handling and health-reporting paths described in the report, then reproduce the duplicate advertise-client-urls scenario with the stated cluster layout. Determine how an existing member owns and validates its client URL. Done means a duplicate URL is rejected or quarantined, health checks verify member identity, and the reproduced orphan-member failure no longer occurs.

Written by the indexing model from the issue text.