[Studio] Discover RocketMQ NameServer services from Kubernetes

### Background

RocketMQ Studio currently requires operators to type and maintain NameServer addresses manually. The registry already stores `k8sNamespace`, but Studio does not use the Kubernetes API to discover NameServer Services.

Unlike Kubernetes certificate lifecycle management, NameServer endpoint discovery is directly related to connecting Studio to RocketMQ. The implementation should use Kubernetes-native service discovery and avoid treating a full Pod scan as the primary path.

### Proposed behavior

Add an on-demand, read-only discovery flow in the NameServer management page:

1. List Services in one explicitly selected namespace and prefer Services exposing the configured NameServer port (default `9876`).
2. Fall back to Service name/port-name and common Kubernetes application-label hints.
3. Fall back to `discovery.k8s.io/v1` EndpointSlice data when no Service candidate is found.
4. Query Pods with standard component/name label selectors, then perform a namespace-scoped image-name scan only as the last fallback.
5. Return ranked candidates with source, confidence, stability and `namesrvAddr`; do not auto-persist or silently select the first candidate.
6. Let the user select a candidate and review it in the existing NameServer registry form before saving.

### Safety and scope

- Namespace is required; no `inAnyNamespace()` or ClusterRole is needed.
- Discovery is disabled by default and creates the Kubernetes client only when requested.
- Use Service DNS as the preferred stable address; EndpointSlice/Pod IPs are explicitly marked unstable fallbacks.
- Do not read Secrets or certificate resources.
- Do not create, update, delete or watch Kubernetes resources.
- Do not add background address mutation or automatic registry synchronization in this change.
- Map Kubernetes authentication/RBAC/transport failures to explicit API errors without exposing tokens, kubeconfig content or cluster URLs.

### Configuration

- enable/disable flag
- NameServer port, default `9876`
- cluster DNS domain, default `cluster.local`
- Pod fallback enable flag and bounded candidate limit
- Kubernetes credentials follow Fabric8 auto-configuration (in-cluster ServiceAccount, `KUBECONFIG`, or standard kubeconfig)

### Acceptance criteria

- A namespace-scoped backend API returns deterministic, deduplicated candidates.
- Service matches stop lower-cost fallbacks.
- EndpointSlice readiness and ports are handled correctly.
- Label-filtered Pod lookup precedes the full namespace Pod image scan.
- The UI supports discovery, empty/error states and explicit candidate selection.
- Unit/controller/API/page tests cover fallback order and the user flow without a live cluster.
- Documentation includes configuration, connectivity limitations and minimum namespace Role permissions for Services, EndpointSlices and Pods.

Start at the NameServer management page, existing NameServer registry form, and the backend API entry point; inspect how Fabric8 Kubernetes auto-configuration is used. Trace the discovery flow from namespace-scoped Services through EndpointSlices and Pod fallbacks, then review the controller/API/page tests. Done means deterministic candidates, explicit selection, safe error handling, documented permissions, and coverage without a live cluster.

Written by the indexing model from the issue text.