agent-platform release v4.44.2

Fixed

• The hook Jobs get memory headroom, and the storage-version backup no longer parses this chart’s own release (giantswarm/agent-platform#593; a lab, 2026-09-19). The pre-upgrade backup hook pod ran with a 128Mi limit and was OOM-killed three seconds into its first kubectl calls — the kernel’s report shows the pod’s cgroup at 128Mi with only sh and one kubectl (17 MiB) alive, the rest held by nothing that was still running — and the Job’s retry pod finished nine seconds later: a headroom problem, not a leak. Measured in the hook image against a large installation (1069 release Secrets, 715 CRDs): one kubectl run peaks near 50 MiB with a cold discovery cache, the decode of the largest release Secret (4.3 MB of JSON) near 35 MiB, helm get values on this chart’s release near 80 MiB — nothing a hook does scales with the cluster, so every hook Job (agent-platform.hooks.job and the self-management hooks) now runs with limits.memory: 512Mi, the requests unchanged at 10m / 32Mi. The one allocation that did grow with the payload is gone: the backup’s release scan pre-filtered with a plain grep for kagent.dev/v1alpha2, which this chart’s own release matches on every installation — the hook script is stored under .hooks[] — so jq parsed every kept revision of the meta release on every upgrade; the pre-filter is now the JSON-encoded marker apiVersion: kagent.dev/v1alpha2\n (the version followed by an encoded newline, what only a manifest document carries; script text encodes the same newline as a doubled backslash), and a 4.x installation’s upgrade runs no jq at all. make verify-kagent-storage-version asserts the marker, refuses the plain grep, runs the marker against two fixtures (this chart’s rendered backup Job stored as a hook next to a manifest without kagent objects; a manifest naming a v1alpha2 object) and pins both hook Jobs’ resources.