Target cluster: place and manage agents on a workload cluster from the installation (HelmRelease kubeConfig.secretRef, status through the cluster's kubeconfig, as the caller) #22

Problem

CPU workload clusters created by the Agent Platform's cluster-manager should run agents that are managed from the installation — no second Backstage or muster on the workload cluster (Timo, 2026-09-04, bumblebee-plans#42 grill Q9). agent-manager composes agent HelmReleases for the cluster it runs on only.

Proposed solution

Give agents an optional target cluster:

• create_agent / POST /api/v1/agents accept a target (organization namespace + cluster name); the composed HelmRelease gets spec.kubeConfig.secretRef pointing at the cluster's kubeconfig Secret (<cluster>-kubeconfig in org-<org>, written by Cluster API) so the agent chart — and its kagent Agent CR — lands on the workload cluster, where the runtime slice (kagent controller and CRDs, installed by cluster-manager's enable_agent_platform) reconciles it.
• list_agents / get_agent / get_agent_status read the workload cluster through a client built from that Secret; the HelmRelease itself stays on the installation's management cluster.
• Writes keep acting as the caller: the workload cluster's apiserver trusts the installation's IdP through the cluster chart's OIDC values set at creation, so the forwarded Dex token is presented there too; where it is not trusted the tool refuses and names the fix.
• Ownership rules (Flux provenance labels, managed: gitops refusal) unchanged.

The agents' outbound path (to the installation's muster and model endpoints) is plain network egress. The inbound path — how a human's chat or Slack message reaches an agent on another cluster — is a separate plan (cross-cluster agent runtime) and not part of this issue.

Acceptance criteria

• An agent created from the installation with a target cluster runs on that cluster; get_agent_status reports it from the workload cluster (feat: place and manage agents on a workload cluster #90, v1.9.0).
• Moved: the agent calling the installation's muster tools from the workload cluster is a criterion of giantswarm/giantswarm#37618 (end to end on spidertron, with v1.9.0's target-cluster placement as the mechanism).
• Without a target the behaviour is byte-identical to today (compose tests unchanged).
• README documents the target, the kubeconfig Secret contract and the identity precondition.

Epic: giantswarm/giantswarm#37611 (Phase 3). Plan: bumblebee-plans#42.