agent-platform release v4.7.15

Fixed

• The managers are pinned to the kagent API version the 4.x line serves (giantswarm/agent-platform#401): model-manager.kagent.apiVersion and agent-manager.kagent.apiVersion are v1alpha3 in the meta chart’s values — the managers’ charts default to auto, which discovers the served kagent.dev version once at start-up and bakes it into the client. On an in-place 3.x → 4.x upgrade nothing in model-manager’s values or pod template changed, so its pod never rolled: it kept the v1alpha2 it had discovered under kagent 0.10 while kagent-crds had replaced the CRDs with v1alpha3 only, and every ModelConfig call failed with list ModelConfigs in kagent: the server could not find the requested resource — a pulled model could not be wired until the pod happened to restart (found by the migration rehearsal, giantswarm/agentlab#143, models-test on a lab upgraded in place from 3.23.1 to 4.7.14; agent-manager’s pod rolled only because its chart moved to 1.1.x). Both charts render the key as the container’s --kagent-api-version=v1alpha3, so the pin is the values change that rolls both Deployments on the cut-over, after kagent-crds is Ready (both dependsOn it), and every manager speaks v1alpha3 from its first request. make verify-components asserts the pin in both forwarded release values; verify-components-charts renders both manager charts with the forwarded values and asserts the argument reaches the pod template. UPGRADE.md “3.x → 4.0 (the kagent line)” carries the operator’s side: the managers roll once, nothing to do. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound; an installation already on 4.x sees both managers roll once on the next reconcile.