agent-platform release v4.28.8

Fixed

• The Substrate worker image follows the chart’s Substrate pin, never the kagent build’s stamp (giantswarm/agent-platform#466). The meta chart pins Substrate and kagent as two independent ranges, and every kagent build stamps into its chart the ateom-gvisor worker of the Substrate it was published against; chart 4.15.2’s open kagent range (>=0.11.0-gs.12 <0.11.1-0) admitted kagent 0.11.0-gs.14, which stamped a 0.0.30-gs.1 worker under the chart’s 0.0.27-gs.9 atelet — Substrate 0.0.30 had renamed the pause bundle (bundles/pause → bundles/_pause), so every golden boot failed with reading …/bundles/_pause/config.json: no such file or directory, every AgentTemplate stayed Ready=False … compiling, and nothing on any hop named the skew (seen on a fresh agentlab on the default chart, giantswarm/agentlab#187; 4.15.5 re-pinned both ranges by hand). The chart now derives kagent.substrateWorkerPool.workerImage for the kagent release from components.substrate.versionRange’s floor — <substrate.image.registry>/ateom-gvisor:<floor> (agent-platform.substrate.workerImage, over the forwarded block like the other derived values) — so the atelet the substrate release installs and the worker the WorkerPool runs are one Substrate release whatever kagent build the kagent range admits; the same 4.15.2 shape now forwards the 0.0.27-gs.9 worker. An installation’s own workerImage stands while its tag is the pinned release (a mirror by another path; substrate.image.registry moves the derived image on its own) and fails the render otherwise, naming the key, the release and the derived image. The Substrate range must confine one release (agent-platform.substrate.validateRange): an exact version or >=X.Y.Z-gs.N <X.Y.(Z+1)-0 — the worker follows the floor and the atelet what Flux resolves, so a later gs.N of the pinned release may reach the control plane ahead of the worker and a 0.0.31 never; 0.x, ~, ^, a <= ceiling or a floor alone fail the render naming the range. make verify-worker-image (tests/verify-worker-image.py) holds the derivation, the mirror, the own-value rule, the 4.15.2 shape, the exact pin, the range guards, and — against the kagent chart the range resolves to — the rendered WorkerPool’s spec.workerImage and that the build was published against the pinned release’s X.Y.Z (its Chart.yaml substrate dependency), so the meta chart’s CI names the day the kagent line moves to another Substrate before the chart’s pin does; verify-components asserts the forwarded image, verify-workerpool the range guard’s precedence. components.substrate / components.substrate-crds move to >=0.0.30-gs.4 <0.0.31-0 (the bounded golden boot, giantswarm/substrate#39, giantswarm/giantswarm#37801): the worker the fleet already runs through kagent 0.11.0-gs.20’s stamp, so an installation following the current chart sees the WorkerPool’s spec.workerImage unchanged and the pool does not roll; the BOM pins it. Not taken: a kagent minor bump on every Substrate-line change (a convention every <0.11.1-0 range in the wild depends on, nothing in the chart holds it) and reading the resolved Substrate version at render time (Flux resolves after the render; the floor is the one version the chart knows, and the ceiling guard is what makes it the runtime’s).