agent-platform release v4.7.14

Fixed

• A connectivity chart release no longer stalls on the completed migrate Job (giantswarm/agent-platform#399). The Job <release>-agent-manager-migrate-<hash> was named with a hash of its image, args and environment so that a changed Job renders under a new name (Job.spec.template is immutable), but its pod template carried labels.common — helm.sh/chart and app.kubernetes.io/version, which change on every chart release while the hash did not — so the next release within the Job’s day-long TTL re-applied the same-named Job with a different immutable template and the apiserver refused it (Job.batch "…-agent-manager-migrate-16c89a3a" is invalid: spec.template: Invalid value: … field is immutable); helm-controller exhausted its retries, rolled the connectivity release back (Stalled=True RetriesExceeded) and every dependant — substrate, kagent, the managers, backstage — read dependency not ready until the TTL removed the Job (found by the migration rehearsal, giantswarm/agentlab#143, on the connectivity release moving 4.7.12 → 4.7.13). Two changes: the pod template carries the stable labels only — app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/component: agent-manager-migrate (the network policy’s selector) and the team label (agent-platform.kagent.migration.podLabels); the Job’s own labels keep labels.common — and the Job’s name hashes the whole rendered pod template (agent-platform.kagent.migration.podTemplate: image, args, environment, identity, labels, everything the apiserver makes immutable), so any template change renders a new Job and an unchanged template is re-applied as is; a chart release changes neither. An installation that has the completed Job of an earlier 4.x release (its template carries that release’s version) sees this release render the Job once more under a new name — Helm creates it and removes the old one — and migrate runs again, idempotent (nothing left to rewrite; the contract phase where its gates are met), instead of the refused apply. make verify-migration packages the connectivity chart at two versions and asserts the Job’s name and spec.template are identical while its own labels follow the chart version, and that a changed image tag or identity changes the name. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound; an installation already on 4.x moves to it on the next reconcile, a stalled connectivity release included (a new chart version resets helm-controller’s retries).