agent-platform release v4.12.3

Fixed

• muster-valkey gets a memory bound of its own (giantswarm/agent-platform#446; gazelle 2026-09-14). The valkey.valkey block set no maxmemory, so Valkey ran with maxmemory 0 and the container limit was its only bound: once muster’s capability cache had grown the dataset to ~246 MB (giantswarm/muster#1217) the kernel killed the process, the pod restarted, loaded the RDB back to the same size and the next background save — a fork, copy-on-write on top of the dataset — tipped it over again: 19 OOM kills in 90 minutes, nine orphaned temp-*.rdb files on the PVC, every muster token refresh blocked while the store was down, the muster connector unusable in the Dev Portal and Claude, until the limit was raised by hand (the entry above makes that limit the default). Now valkey.valkey.valkeyConfig — the upstream subchart’s raw valkey.conf fragment, which the chart had left empty — carries maxmemory 640mb and maxmemory-policy volatile-lru (evict the least recently used key that carries a TTL; every muster record does, and the store is a cache: an evicted token is one re-sign-in, an evicted capability entry one re-list on the next connect): maxmemory at ~60 % of the 1Gi limit leaves the fork’s copy-on-write pages, the client buffers and the allocator their headroom under the cgroup, and a store that grows past it evicts instead of dying. An installation’s own valkeyConfig replaces the fragment whole. make verify-valkey (tests/verify-valkey.py) holds the fragment, maxmemory at or under two thirds of the limit and above the request, the policy, no AOF, and the override’s passage (helm/agent-platform/ci/test-valkey-override-values.yaml). The config checksum rolls the muster-valkey pod once more (Recreate, a few seconds without the store; the RDB on the PVC carries the data across) — UPGRADE.md. Lab proof (agentlab, platform.chartPath from this branch): the live muster-valkey answers CONFIG GET maxmemory = 671088640 and maxmemory-policy = volatile-lru, agentlab platform-test passes.