chore(gateway-api-crds): update the vendored bundle to Gateway API v1.6.1 - #3872

What this PR does

Bumps the vendored Gateway API CRD bundle in packages/system/gateway-api-crds from v1.5.1 to v1.6.1. The package Makefile pins the upstream ref, so the change is that pin plus the re-rendered templates/crds-experimental.yaml.

The bundle version is not only bookkeeping: it is a compatibility signal consumers read at runtime. Every CRD in the bundle carries a gateway.networking.k8s.io/bundle-version annotation, and a Gateway API controller can read it off the gatewayclasses CRD to decide whether the installed bundle matches the one it was built against. Controllers that do this typically accept any patch release but require an exact major and minor match, and report SupportedVersion=False with reason UnsupportedVersion on their GatewayClass when the minor differs — a status condition that surfaces the skew rather than a functional break. The Cloudflare Tunnel Gateway API controller proposed for the platform in #3858 is built against Gateway API v1.6.1 and performs exactly that comparison, so against the v1.5.1 bundle shipped today its GatewayClass reports the bundle unsupported, and with this bump it reports supported. Neither change depends on the other landing first: this PR only moves the bundle, and the check lives entirely on the consumer side.

One consequence worth stating plainly, since it will outlive this PR: an exact-minor check makes the shipped bundle version a coupled pin for any such controller. A future bump to v1.7.x flips the same condition back to UnsupportedVersion until that controller is rebuilt against the newer bundle, so the two want to move together.

The bundle still emits the same twelve CustomResourceDefinitions and the same safe-upgrades.gateway.networking.k8s.io ValidatingAdmissionPolicy pair. Every CRD still carries the helm.sh/resource-policy: keep stamp the Makefile's post-processing step adds, and the chart's unit tests pass unchanged.

Two kinds change their version surface: TCPRoute and UDPRoute gain a served v1 that takes over as the storage version, and their v1alpha2 stays served with a deprecation marker. Every other kind keeps exactly the versions it served at v1.5.1. That matters because the Cilium operator resolves GatewayClass, Gateway, HTTPRoute and GRPCRoute in v1, ReferenceGrant in v1beta1 and TLSRoute in v1alpha2 before it enables its Gateway API controller; all six are still served by the v1.6.1 bundle. TLSRoute in particular keeps v1alpha2, which the tenant gateway controller, the platform TLSRoute templates and the tenant hostname admission policy all address.

Schema changes are small and land on fields nothing in this repository sets. sessionPersistence.idleTimeout is gone from HTTPRoute, GRPCRoute and XBackendTrafficPolicy — removed upstream under GEP-1619 because no implementation ever implemented it and HTTP cookies have no native idle-timeout mechanism, so no working behaviour is lost even though the field disappears from the schema; HTTPRoute gains a lower bound on retry.attempts and now rejects duplicate retry.codes; ReferenceGrant requires spec at the root. In the other direction, Gateway infrastructure annotations and frontend CA certificate references go from a limit of 8 to 16, and TLSRoute hostnames from 16 to 1024. No CEL validation rule anywhere in the bundle was changed or removed — the only six added belong exclusively to the new TCPRoute and UDPRoute v1 schemas.

The Gateway and HTTPRoute objects the tenant gateway controller renders were serialized across all three certificate modes and checked against both the v1.5.1 and the v1.6.1 schemas; the two runs are identical, so the bump does not change what the controller can create. go.mod still pins sigs.k8s.io/gateway-api v1.4.1 and this PR deliberately leaves it there — the CRD bundle and the Go client types have been on separate versions since before this change, and nothing the controller emits depends on the gap.

One thing to know before the next bump: from v1.6 on, the two things upstream calls the experimental bundle disagree. This package follows config/crd/experimental, the kustomization, which emits 12 CRDs at v1.6.1; the published experimental-install.yaml for the same tag emits 13, the extra one being xbackends.gateway.networking.x-k8s.io, new in v1.6 and not listed in the kustomization. At v1.5.1 the two agreed, so there was nothing to choose between. Nothing in this repository references XBackend and no vendored CRD depends on it, so following the kustomization costs nothing today — but whoever bumps next inherits the choice, and it should be made deliberately rather than by whichever command gets typed.

The second commit corrects a comment this bump invalidated. It claimed TLSRoute stays at v1alpha2 through Gateway API v1.5 and that the promotion to v1 was still upstream-only; TLSRoute has been served at v1 since v1.5.0, so the claim was already wrong before this bump and the version range it named is now wrong too.

The third commit closes a gap that correction exposed. cozystack-route-hostname-policy-tls named v1alpha2 alone while the bundle serves tlsroutes at v1, v1alpha2 and v1alpha3 — three served versions against one named. The gap is not new and this bump neither creates nor widens it: the v1.5.1 bundle and the v1.6.1 one serve the same three versions, with the same two marked deprecated. Coverage of the two unnamed versions rested entirely on request conversion, because matchPolicy is unset on both rules in that file and so defaults to Equivalent, which rewrites a request submitted under any served version into the one the rule names before the policy sees it. That is why there is no bypass to demonstrate, and equally why the arrangement is brittle: the conversion has nothing left to convert into once no named version is served, and a rule that selects nothing is not caught by failurePolicy: Fail, because nothing failed. The rule now names all three, which is the shape the HTTPRoute rule above it already used, and hack/route-hostname-policy-version-coverage.bats reads the served versions out of the vendored bundle and fails when a policy does not cover every one of them — so a future bundle move cannot outrun the list silently, in either direction.

The guard was checked by failing it, not only by watching it pass. Injecting a served v9 into a copy of the vendored bundle and leaving the policy untouched makes it report missing: v9 and exit non-zero; dropping a version from the policy list with the bundle untouched fails the same way from the other side. That is the drift it exists to catch, in both directions.

Two notes for whoever reads the release: the TCPRoute and UDPRoute storage version moves from v1alpha2 to v1, and while nothing in this repository ships either kind and the CRDs declare no conversion block, an upgraded cluster accumulates both entries in status.storedVersions — inert today, load-bearing only if a later bundle stops serving v1alpha2.

Four improvements are named rather than made. The version-coverage guard collects apiVersions from every resourceRules entry mentioning the resource without also matching on apiGroups or operations, so a rule in another group, or one scoped to a single verb, would donate its versions to the set coverage is measured against; the chart's own suite pins the group and the resource on the rule it checks, which closes that a layer below, and a comment saying so would cost nothing. The coverage guard asserts that the current tree is clean but ships no negative fixture, where two sibling checkers in hack/ feed themselves a broken input and assert they complain; its failure path was exercised by hand in both directions but is not encoded, so a refactor that neutered it would keep reporting green. The same guard would also fit the Gateway listener policy in the same chart: its rule names ["v1", "v1beta1"] for gateways, which is exactly what the bundle serves today, so nothing is wrong there — but the reason the guard exists (the version set lives in another package, is vendored from upstream, and moves on make update) applies to it word for word, and extending it costs one line. And the CRD package's test suite already pins the rendered document count so that a change in what the kustomization emits shows up there, and it could pin gateway.networking.k8s.io/bundle-version for the same reason: nothing in the repository asserts which Gateway API version is actually vendored, so a re-run of make update against a different ref lands silently.

Closes #3789.

Screenshots

Not a UI change.

Downstream repositories

Walked the trigger map in docs/agents/contributing.md against the diff, file by file: neither packages/system/gateway-api-crds/Makefile nor its rendered CRD template matches any entry. Leaving every box empty rather than ticking the "no downstream repository" line, because the docs site carries a Gateway API version statement that is already inaccurate and needs a decision that is not mine — content/en/docs/next/networking/gateway-api.md and its v1.5 and v1.6 copies say Gateway API v1.5 ships TLSRoute at v1alpha2 and that the graduation to v1 is still upstream-only, when v1.5.0 already shipped TLSRoute v1 as the storage version.

Release note

chore(gateway-api-crds): update the vendored Gateway API CRD bundle to v1.6.1. TCPRoute and UDPRoute gain a served v1 that becomes their storage version, with v1alpha2 still served and now deprecated; every other kind keeps the versions it served at v1.5.1. Upstream removed `sessionPersistence.idleTimeout` from HTTPRoute, GRPCRoute and XBackendTrafficPolicy — the field is not set by anything Cozystack renders, but a hand-written route that carries it loses it silently on its next write, with no admission error.