agent-platform release v4.9.7

Fixed

• The storage-version backup hook stops the 0.x kagent release from re-applying the CRDs it deletes (giantswarm/agent-platform#416): on graveler’s cut-over (giantswarm/giantswarm#37745, meta 3.23.1 → 4.9.1 through the cluster’s Flux) the still-installed kagent 0.3.3 wrapper HelmRelease — crds: CreateReplace, in an upgrade-retry loop because the fleet’s flag PR (agentPlatform.kagentApiV2: true) had landed before the bound lift, its render refused on every retry (additional properties 'harness' not allowed) — re-applied modelconfigs, remotemcpservers and modelproviderconfigs.kagent.dev one second after <release>-kagent-storage-version-backup had deleted them, and kagent-crds failed six times with status.storedVersions[0]: Invalid value: "v1alpha2" and stalled; recovery was by hand. The backup hook now patches spec.install.crds and spec.upgrade.crds to Skip on every HelmRelease a deleted CRD’s helm.toolkit.fluxcd.io/name + namespace labels name before it deletes (the 4.x manifest carries no crds policy for the kagent release: helm-controller’s client-side three-way merge drops the patch on apply, a server-side apply leaves it inert on a release whose chart ships no crds/; a gone owner is tolerated), then watches the CRDs stay absent for 60 s — one that comes back is deleted again and the hook fails naming the owner, so Flux’s retried upgrade finds them gone. Rehearsed on a 3.23.1 agentlab upgraded in place to this chart with the 0.x release held in the loop and reconciled every 5 s: the CRDs stayed absent, kagent-crds installed on its first attempt. make verify-kagent-storage-version asserts the patch, its order and the watch; UPGRADE.md (“3.x → 4.0”, both sections) names the race and the order of the two fleet PRs. Installations act: none — the hook runs on the cut-over upgrade; an installation that lands the flag and the bound lift within one Flux interval never enters the loop at all.