[Feature] TrafficManagerBackend status should reflect data-plane truth: endpoint monitor status + DNS-label re-validation

[ytimocin]

What

1. Acceptance-only condition. TMB's sole condition type is Accepted (api/v1beta1/trafficmanagerbackend_types.go:143-158), doc-commented as not indicating data-plane propagation. ARM's endpointMonitorStatus (Online/Degraded/CheckingEndpoint) is never read in controller code, so the CRD cannot say whether an endpoint is probing healthy or in DNS rotation. (When endpoints are invalid, the condition message names only the first, non-deterministically — pkg/controllers/hub/trafficmanagerbackend/controller.go:344-346.)
2. DNS-label drift is invisible. The endpoint is created from the member LB public IP, which requires dnsSettings.domainNameLabel. The label is read once (pkg/controllers/member/serviceexport/controller.go:379-381; the comment notes the PIP isn't monitored), the hub is event-driven off a bool,omitempty field, and invalid services are deliberately not requeued (controller.go:356-358) — an out-of-band label removal goes undetected forever while the CRD stays green.

Why

Health-gated failover and progressive cutover need probe truth in the CRD; today consumers must poll ARM directly (we built exactly that workaround and want to delete it). The docs pitch a Kubernetes-API-driven experience but the only documented verification is nslookup.

Proposed

• Reflect endpointMonitorStatus into per-endpoint status (same ARM client, read-only) plus an aggregate condition (e.g. Healthy).
• Periodically re-verify the PIP DNS label; set DNSLabelMissing when it disappears.

Both need a new periodic trigger — the TM controllers are purely event-driven today (no RequeueAfter/SyncPeriod; generation-filtered watch). That's a design point to settle here, and why this is one issue: same controller, shared resync mechanics.