Validate TiFlash advertised endpoints before registering a new store with PD

Bug Report

Problem

A TiFlash process can start with valid local listeners while advertising store, peer, and status endpoints that are intended for a different or future TiFlash instance.

In a reproduction, an orphan TiFlash registered first with:

[flash]
service_addr = "0.0.0.0:3931"

[flash.proxy]
addr = "0.0.0.0:20171"
advertise-addr = "127.0.0.1:20171"

[server]
engine-addr = "127.0.0.1:3931"
advertise-status-addr = "127.0.0.1:20293"

PD accepted the orphan as a TiFlash store because these addresses were not yet present. A later real TiFlash using the same intended endpoints failed during put store to PD with duplicated store address.

Impact

An orphan or misconfigured TiFlash can pre-claim a future store identity and block scale-out, replacement, or recovery. Stopping the process is not sufficient; the incorrect PD store metadata must be removed safely.

Expected behavior / possible improvement

Before registering with PD, TiFlash should validate that its advertised store, peer, and status endpoints route back to the same TiFlash instance, or emit a strong actionable warning when identity cannot be proven.

The validation should use an instance/store identity round trip where possible, rather than relying only on local interface matching, to remain compatible with container networking, DNS, Services, and load balancers.

Begin with the reproduction configuration and the TiFlash put store to PD registration flow described in the issue. Trace how the advertised store, peer, and status endpoints are handled before registration. Done means preventing incorrect pre-claims through identity validation, or producing a strong actionable warning when identity cannot be proven.