Support standalone panel/API installs without a local Kubernetes cluster #629

Problem

The panel/API currently requires a Kubernetes cluster, automatically exposes it as local, and depends on Kubernetes Secrets and Cluster CRs for management state. Scaling the operator to zero leaves these dependencies in place. This prevents a standalone central panel on a Docker host and requires an operator on the management cluster for remote health reporting.

Requested behavior

• Run only the panel and API, including through Docker Compose, without kubeconfig, an operator, agents, or an implicit local cluster.
• Persist cluster registrations and panel credentials independently of Kubernetes; protect credential material at rest.
• Start with an empty fleet and explicitly register remote Kubernetes clusters running their own operator and optional agent gateway.
• Preserve remote inventory, workload/module management, gateway access, and existing authorization boundaries.
• Provide independent Helm component switches and a documented panel-only profile while preserving the existing combined installation defaults.
• Cover empty installs, persistence/restarts, credential isolation and the deployment matrix with regression tests.

The implementation should retain Kubernetes-native workload reconciliation on remote clusters. It should not run games on the panel host or silently migrate an existing installation's management state.