agent-platform release v4.103.2

docs/serving-presets.md: how a serving preset is added (giantswarm/agent-platform#751): the preset file, the render checks (verify-serving-slice, verify-preset-weights, the shipped count in verify-wiring) and the kubernetes-cka-v2 benchmark run against the preset as served, whose mean score and range the PR states. The pull request template carries the preset line.

Substrate workers schedule only where atelet runs: components.substrate{,-crds}.versionRange is >=1.3.0 <1.4.0 (giantswarm/agent-platform#756). atelet’s PriorityClass never preempts, so while the atelet DaemonSet rolled on a node without spare CPU, a worker pod scheduled in the gap took the CPU the old atelet pod freed: the new atelet pod stayed Pending, the rollout stopped at that node, and the substrate upgrade timed out and rolled back. The Substrate line’s 1.3.0 takes WorkerPool.spec.template.podAffinity (giantswarm/substrate#98), and from it on the chart derives kagent.substrateWorkerPool.template.podAffinity, a required term on the atelet pods (app: atelet in components.substrate.targetNamespace) with topologyKey: kubernetes.io/hostname. An installation’s own podAffinity stands instead; below 1.3.0 the key is refused. 1.3.0 is the line on kagent-dev/substrate v0.2.0-beta5, released as a minor, so the next re-pin is 1.4.0. The kagent WorkerPool’s worker image follows the floor to ateom-gvisor:1.3.0. make verify-workerpool asserts the derived term, its gate and an own podAffinity.