agent-platform release v4.9.1

Fixed

• The hook Jobs are policed by the chart (giantswarm/agent-platform#413): every hook of this chart — the kagent namespace hook, the two storage-version hooks, the self hooks, the ordered teardown — runs kubectl against the apiserver under the hook identity’s pod labels (app.kubernetes.io/instance: <release>, app.kubernetes.io/component: hooks), and the chart rendered no network policy for them; on a cluster that is default-deny for every endpoint (Cilium policyEnforcementMode: always) the pre-upgrade backup hook of 4.7.13+ looped on dial tcp <apiserver>:443: i/o timeout until its deadline and every meta-chart upgrade failed — the first 4.x installation sat on 4.7.12 from 2026-09-11 23:55Z for that reason. templates/hooks/netpol.yaml renders one policy for the hook identity as a hook object (a pre-install/pre-upgrade hook runs before the release’s manifests exist): weight -10 next to the identity’s ServiceAccount and ClusterRoleBinding, the same delete policy, at all five hook events with the bundled engine and at the storage-version hooks’ four without it; egress to the apiserver only — the kube-apiserver entity in the cilium flavour, networkPolicy.kubernetes.apiServerCIDR in the kubernetes one — gated on networkPolicy.enabled and networkPolicy.flavor like every policy the platform renders. make verify-hooks-netpol asserts both flavours, the events per engine shape, the off switches and that every hook Job’s pod carries the selected labels. An installation that hand-wrote such a policy (the connectivity hooks’ sibling, #367) can drop the meta release’s copy once this release is in. No fleet installation acts — the release stays inert behind the fleet’s <4.0.0 bound.
• The storage-version backup hook no longer lists the cluster’s Helm release Secrets with their payloads in one call (giantswarm/agent-platform#414): the re-point step (#398) fetched every helm.sh/release.v1 Secret cluster-wide through a client-side jsonpath listing — kubectl get collects the whole objects before such a printer runs — so the pod’s memory grew with the cluster’s Helm history and was OOM-killed at its 128Mi limit on the first 4.x installation (351 release Secrets, 61 MB of payload), failing the hook right after no kagent CRD stores v1alpha2: nothing to migrate. The listing is now the apiserver’s Table (kubectl get … --no-headers, names only), each Secret is read and decoded on its own onto the emptyDir as before, and jq runs only on a manifest that names kagent.dev/v1alpha2 at all (grep first) — memory bounded by the largest single release, not their sum. make verify-kagent-storage-version asserts the Table listing, the absence of a client-side printer and the pre-filter ahead of jq.