agent-platform release v3.20.2

Fixed

• The kagent controller metrics Service the connectivity chart renders (<release>-kagent-controller-metrics, the target of its ServiceMonitor) selected the controller pods with the connectivity release’s own app.kubernetes.io/instance label. Under the retired standalone umbrella every subchart shared one release name, so that matched; under the meta chart each component is its own release — the kagent pods carry app.kubernetes.io/instance: kagent, the component key the meta chart fixes as the release name — and the Service had no endpoints: the controller was never scraped on any installation with kagent and the monitors on (#305). The selector now names kagent’s release through the new connectivity helper agent-platform.kagent.releaseName; the fallbacks of the controller route’s backend host, the UI route’s Service and the oauth2-proxy Service (kagent.fullnameOverride / kagent.oauth2-proxy.fullnameOverride, pinned in values.yaml, else .Release.Name) go through agent-platform.kagent.fullname / the release-name helper too — the same wrong assumption, latent behind the pins. No compatibility knob: the meta chart is the chart’s only consumer. No installation needs to act: the Service’s selector changes (a Service update, no pod rolls) and kagent controller scraping starts working; every other object is byte-identical. make verify-global asserts the selector and that no kagent template falls back to .Release.Name.
• A first helm install with components.kagent.enabled on a cluster without the kagent namespace deadlocked: the kagent chart installs into kagent.namespaceOverride while its HelmRelease targets the platform namespace (so install.createNamespace never creates kagent), and the one chart object that does create it — the connectivity chart’s Namespace — sits in a release that dependsOn kagent. Every kagent attempt failed with namespaces "kagent" not found until the retries were exhausted, everything behind kagent waited, helm install --wait timed out (#306). With the bundled engine the meta chart now runs one pre-install,pre-upgrade hook Job, <release>-kagent-namespace (weight -8, alpine/k8s, as the hook ServiceAccount, whose own hook events gain pre-install,pre-upgrade while this hook renders): it creates the namespace when it is missing, waits out one that is still terminating (the reinstall right after an uninstall), and leaves an existing one alone. The Namespace is deliberately not an object of the meta release — the connectivity release renders and tracks it, adopting the hook-created one exactly as it adopts the one Giant Swarm’s bases pre-create, and two Helm releases must never track one object. Not rendered with the engine off (the fleet’s pure render is byte-identical; a cluster’s own Flux gets the namespace out of band), with kagent off, with kagent.namespaceOverride empty or equal to the HelmReleases’ target namespace. Measured on kind (kagent on, no namespace): helm install --wait deployed, helm upgrade idempotent, helm uninstall --wait clean with the namespace gone through the connectivity release, reinstall clean. make verify-engine asserts the hook and its absences; the ATS kind smoke can turn kagent on from this version.