Standardize Metrics Specification for MCS API Implementations

As multi-cluster environments scale, monitoring the performance and health of Multi-Cluster Services (MCS) implementations (e.g., Submariner, Cilium) becomes difficult. MCS controllers must constantly synchronize `EndpointSlices` from the source (`ServiceExport`) cluster to the destination (`ServiceImport`) cluster. Significant delays in this synchronization can result in silent traffic blackholes, particularly during deployment rollouts with high pod counts.

### Describe the solution you'd like
Introduce a standardized set of guidelines or Prometheus metric definitions for MCS controllers. While the implementation code lives across different provider repositories, standardizing the metric names, types, and labels ensures that platform engineers can build consistent dashboards and SLO alerts regardless of the underlying MCS provider they deploy.

A dedicated `/metrics` endpoint exposing core control plane performance metrics as a recommended conformance target.

As a starting point, maybe introduce a metric like `mcs_endpointslice_sync_latency_seconds` to track the latency of mirroring endpoints across cluster boundaries.

Start by reviewing how MCS controllers such as Submariner and Cilium synchronize EndpointSlices between ServiceExport and ServiceImport clusters. Compare the metrics currently exposed by those provider implementations, if available, and identify the metric names, types, labels, and /metrics expectations that need standardization. Done means a provider-neutral specification or conformance target is agreed on.

Written by the indexing model from the issue text.