agent-platform release v3.21.2

Fixed

• The data-plane NetworkPolicy admits the Prometheus scrape of the agentgateway data plane (pod port 15020, /metrics), in both flavours. The PodMonitor this chart renders targets that port, but the policy’s only ingress rule listed the Gateway’s listener ports — 8080, and 8081 once llmRouting is on — so Cilium dropped every scrape: measured on graveler, the target reported up=0 with scrape_samples_scraped=0 for as long as the monitor had existed, JobScrapingFailure sat pending against it, and not one GenAI or HTTP series ever reached the tenant’s Mimir. The monitor was therefore inert from the moment it was added, and the LLM cutover’s whole point — tokens, cost and latency per model call — produced nothing on an installation that had done both rollout steps correctly. A second fromEntities: ["cluster"] rule now admits 15020, exactly as the sibling controller policy admits the controller’s own 9092/9093; the port is fixed by the agentgateway controller (it names the container port metrics and sets the prometheus.io/* annotations), not an operator choice, so it is written literally rather than as a value. Unconditional, like that sibling rule, because a cluster may scrape by pod annotation with no PodMonitor at all. An installation with the agentgateway component on gains one ingress rule on that policy and starts reporting the data plane’s metrics; nothing else changes and no pod rolls. make verify-llm-routing asserts the port in both flavours and with llmRouting off, where the monitor already renders; reverting either template fails it.