agent-platform release v4.4.0

Added

• The connectivity chart renders one platform Harness per managed namespace (giantswarm/agent-platform#344, bumblebee-plans#51 D5). On kagent API v2 how an agent runs is a kagent.dev/v1alpha3 Harness: a digest-pinned Go ADK runtime image, an environment and the Substrate policy an AgentTemplate runs under; a template becomes Ready only when a Harness admits it (allowedAgentTemplates.selector), its readiness read from AgentTemplate.status.harnesses[] (Harness.status is never written). 4.0 renders exactly one Harness, kagent (the kagent runtime only — no free list of arbitrary types; a second runtime is a later object), in each managed namespace (today the kagent namespace; a WorkerPool and a workerPoolRef are namespace-local): workload.image = kagent.harness.image (the line’s Go ADK image by digest — a tag fails the render naming the requirement, as the CRD rejects it; the digest moves with kagent.tag on a re-pin), env = KAGENT_PROPAGATE_TOKEN=true (the Go ADK re-emits the caller’s bearer on its MCP calls, so muster sees the person; the private-skills credential is added only if the D8 spike chooses the per-namespace-credential route — undecided, nothing more today), substrate.workerPoolRef.name = kagent.substrateWorkerPool.name (the meta chart’s default WorkerPool, forwarded), snapshotPolicy.location = kagent.harness.snapshotLocation (#342), and allowedAgentTemplates.selector.matchLabels = {agent-platform.giantswarm.io/harness: kagent} — the one label the Generic agent chart 1.x sets on every template (giantswarm/agent#25), the whole admission contract. make verify-kagent-harness (tests/verify-kagent-harness.py) asserts exactly one Harness with the shape, the workerPoolRef following kagent.substrateWorkerPool.name, a tag image failing the render and none while kagent is off; make verify-kagent-crds now also validates the rendered Harness against the line’s CRD at the pinned release.
• The Substrate WorkerPool’s replicas and pod template are the platform’s capacity and scheduling knobs (giantswarm/agent-platform#344). kagent.substrateWorkerPool.replicas and kagent.substrateWorkerPool.template (resources, nodeSelector, tolerations, nodeAffinity, priorityClassName) — the kagent chart’s WorkerPool values forwarded by the meta chart — carry the capacity: one worker hosts one actor at a time, so a worker’s resources.limits bound one agent’s sandbox (memory → RAM, CPU → vCPU count) and replicas bound the concurrently active agents. Defaults with sizing guidance in the README (“Agent Substrate: worker capacity”): four workers, each requesting 250m/512Mi and limited to 2 vCPU / 2Gi (an idle worker holds ~16Mi; a Go ADK golden boot and turn stay well under the limit — measured in agentlab), the pool pinned to amd64 (#342). The Generic chart 1.x has no per-agent runtime/replicas/resources/nodeSelector/tolerations any more (giantswarm/agent#25); capacity is the WorkerPool (UPGRADE.md).