Block remote direct apply: verify exact local k3d target or require GitOps

[AntoineToussaint]

Problem

The deploy path is fail-open for remote Kubernetes targets:

• pkg/deployments/manager.go imports images when the current context looks like k3d, but warns and continues when import fails.
• A non-k3d context simply skips import and continues to kubectl apply.
• pkg/deployments/kubernetes.go resolves a kubeconfig but does not prove the actual server/context/cluster matches the environment's declared cluster kind and identity.
• cmd/deploy/{service,module}.go directly applies by default; --render-only is optional.

This means an omitted flag or stale kubeconfig can direct-apply service manifests to EKS, bypassing the required signed Git commit, review, Argo policy boundary, and promotion evidence.

Required invariant

Direct Kubernetes mutation is allowed only for an exact, verified local k3d target. EKS/GKE/AKS/external targets are render/publish/observe only.

Acceptance criteria

• Resolve and compare declared environment kind, kubeconfig, context, API server, and k3d-owned cluster identity before any mutation.
• Permit direct apply only when all checks prove the selected target is the declared local k3d cluster.
• Fail closed when k3d image import/pull fails or when the context changes between plan and apply.
• Reject direct apply for eks, gke, aks, and external; direct users to the GitOps render/publish workflow.
• Use the same invariant in CLI and control-plane deploy paths; reconcile renderOnly and DryRun semantics.
• Bind the verified target identity and rendered tree digest into the deployment result/evidence.
• Add hostile tests for stale current context, mismatched kubeconfig, renamed non-k3d context, import failure, remote kind with a k3d-looking context, and context swap after validation.
• Preserve an explicit no-mutation render operation for every target kind.