Support isolated NVCF control planes in one Kubernetes cluster

Problem

The self-managed NVCF stack and NVCA deployment currently assume a single control plane per Kubernetes cluster. Resource names, namespaces, routes, migration state, and operator watches can overlap when a second control plane is installed.

Expected behavior

Operators should be able to install two control planes in one Kubernetes cluster using separate namespaces and a stable control-plane identifier. Each control plane must create, watch, update, and delete only its own resources while intentionally shared cluster-scoped prerequisites remain safe.

The legacy single-control-plane configuration must keep its existing names and behavior.

Acceptance criteria

• Control-plane and compute-plane resources are derived from a validated control-plane identifier.
• API routes, services, secrets, ConfigMaps, jobs, labels, migrations, and operator watches are isolated.
• A control plane cannot reconcile resources owned by another control plane.
• Preexisting mirrored secrets converge correctly during agent startup, including concurrent informer updates.
• Installing, upgrading, restarting, and removing one control plane does not affect another.
• Successful uninstall removes plane-specific namespaced and cluster-scoped hook resources.
• Rendering, unit, integration, and local multi-control-plane lifecycle regressions cover both named and legacy modes.