feat: Gateway-API as an alternative to the Ingress in eight charts

Group 1 of the #114 sweep: the charts that render exactly one Ingress object
and set no behaviour-bearing nginx annotation - bentopdf, garage, patchmon,
rallly, searxng, sure, urlaubsverwaltung, voucher-vault.

Each gets the form the pilot (cyberchef, PR #115) fixed and template-chart
carries: an httpRoute block (enabled/parentRefs/hostnames, off by default), a
template rendering ONLY an HTTPRoute with parentRefs - no Gateway, no
gatewayClassName, no Certificate, no implementation-specific policy object -
render aborts on both modes at once (naming both value paths), on an empty
parentRefs and on a missing hostname, empty hostnames meaning [ingress.domain],
a schema entry closed against unknown keys with an open parentRef definition,
and a NOTES.txt that names the active mode and what the mode costs.

Minor, additive, defaults unchanged: `helm template` with each chart's CI
values is byte-identical to origin/main for seven of the eight, and for sure
identical in every rendered value (the diff is two YAML comment lines).

Three findings that were not in the plan, each argued in the file it changes:

  sure derived RAILS_ASSUME_SSL/RAILS_FORCE_SSL from ingress.enabled alone.
  Gateway mode sets that false by construction while TLS is still terminated at
  the Gateway, so both flags would have gone false: insecure cookies, no HSTS,
  http:// links, with a Ready pod and a working UI as the only symptom. They now
  read sure.publishedOverTls (ingress.enabled OR httpRoute.enabled), which is
  ingress.enabled while httpRoute.enabled is false - hence still Minor.

  garage claimed, in its Ingress template and its schema, that nothing outside
  that template reads ingress.domain. The HTTPRoute reads it, so the claim now
  holds only while both modes are off. Corrected rather than left standing.

  garage also depends on an upload limit it does not set: its annotations
  comment tells the operator to set proxy-body-size: "0" because ingress-nginx
  truncates S3 uploads at 1 MB. proxy-body-size has no Gateway-API counterpart,
  so its Gateway-mode NOTES prints that the limit is the Gateway's. README's
  list of affected charts named five and now names garage as a sixth.

clusterIssuer needed no change in any of the eight: its only required() sits
inside the Ingress template behind ingress.enabled, the same no-op the pilot
found. Annotation guidance that stops applying in Gateway mode moved into the
Gateway branch of NOTES.txt for bentopdf (X-Robots-Tag) and searxng
(forward-auth).

CI: one render overlay per chart under ci/httproute/, so the assertion is not
vacuum-green - ci/run-httproute-match-test.sh goes from 4 held assertions over
2 charts to 20 over 10. The install-test fixtures stay in Ingress mode: the
install runs one configuration per chart, cyberchef already pays that price
against the real Gateway-API CRDs, and for garage the Ingress is the only place
its Service port is referenced by NAME.

Not proven, by construction: that traffic flows. No Gateway controller runs in
CI. Not run locally either: k3d, Docker, Trivy.

Part of #114

ci/httproute/bentopdf.yaml

@@ -0,0 +1,31 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# WHY AN OVERLAY AND NOT A CHANGE TO ci/bentopdf/test-values.yaml, which is
+# what the pilot did for cyberchef: the install-test runs exactly ONE
+# configuration per chart, and the two modes are mutually exclusive. cyberchef
+# already pays that price and gives the install-test its HTTPRoute against the
+# real Gateway-API CRDs. Spending it a second time here would drop this chart's
+# Ingress from the install-test for a schema this repository now exercises
+# anyway. So the install keeps testing the Ingress; the route is held at render
+# level, which is where its two silent failure modes live.
+#
+# ingress.enabled: false is not optional here. The two modes are mutually
+# exclusive and the chart aborts its own render when both are true, so an
+# overlay that only switched httpRoute on would turn this test red.
+#
+# ingress.domain comes from ci/bentopdf/test-values.yaml, which this overlay
+# sits on top of - httpRoute.hostnames is left empty on purpose, so the
+# fallback to ingress.domain is what the test exercises.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/garage.yaml

@@ -0,0 +1,35 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# THIS CHART IS THE ONE WHERE THE OVERLAY EARNS ITS KEEP TWICE OVER, and the
+# reason is in ci/garage/test-values.yaml: that fixture keeps the Ingress ON
+# deliberately, so the install-test proves the Service port it names BY NAME
+# ("s3") exists. An HTTPRoute cannot make that reference - backendRefs takes a
+# PortNumber - so garage is the one chart in the sweep whose route renders a
+# port NUMBER out of a VALUE (garage.ports.s3), not a literal. Switching the
+# install fixture into Gateway mode would have traded a check that catches a
+# renamed port for one that does not, and would have given up garage's only
+# Ingress coverage at the same time. Here the number is held instead by this
+# test, which fails when a backendRef names a port the same render's Service
+# does not expose - exactly the drift the value introduces.
+#
+# ingress.enabled: false is not optional here. The two modes are mutually
+# exclusive and the chart aborts its own render when both are true, and this
+# chart's fixture has the Ingress on, so the overlay must switch it off.
+#
+# ingress.domain comes from ci/garage/test-values.yaml. Note that garage ships
+# ingress.enabled: false AND httpRoute.enabled: false, so without this overlay
+# the chart renders no route at all - which is correct and is why the overlay
+# exists rather than a changed default.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/patchmon.yaml

@@ -0,0 +1,29 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# An overlay and not a change to ci/patchmon/test-values.yaml: the install-test
+# runs exactly ONE configuration per chart and the two modes are mutually
+# exclusive, so switching the fixture would drop this chart's Ingress from the
+# install for a CRD schema cyberchef's fixture already exercises against the
+# real Gateway-API CRDs. The install keeps the Ingress; the route is held here,
+# at render level, which is where its two silent failure modes live.
+#
+# ingress.enabled: false is not optional here - the chart aborts its own render
+# when both modes are true.
+#
+# ingress.domain comes from ci/patchmon/test-values.yaml and keeps feeding
+# CORS_ORIGIN and the probes' Host header in this mode too; httpRoute.hostnames
+# is left empty on purpose, so the fallback to ingress.domain is what the test
+# exercises - and the two therefore cannot disagree here.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/rallly.yaml

@@ -0,0 +1,27 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# An overlay and not a change to ci/rallly/test-values.yaml: the install-test
+# runs exactly ONE configuration per chart and the two modes are mutually
+# exclusive, so switching the fixture would drop this chart's Ingress from the
+# install for a CRD schema cyberchef's fixture already exercises against the
+# real Gateway-API CRDs.
+#
+# ingress.enabled: false is not optional here - the chart aborts its own render
+# when both modes are true.
+#
+# ingress.domain comes from ci/rallly/test-values.yaml and keeps feeding
+# NEXT_PUBLIC_BASE_URL in this mode too; httpRoute.hostnames is left empty on
+# purpose, so the fallback to ingress.domain is what the test exercises.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/searxng.yaml

@@ -0,0 +1,27 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# An overlay and not a change to ci/searxng/test-values.yaml: the install-test
+# runs exactly ONE configuration per chart and the two modes are mutually
+# exclusive, so switching the fixture would drop this chart's Ingress from the
+# install for a CRD schema cyberchef's fixture already exercises against the
+# real Gateway-API CRDs.
+#
+# ingress.enabled: false is not optional here - the chart aborts its own render
+# when both modes are true.
+#
+# ingress.domain comes from ci/searxng/test-values.yaml and keeps feeding
+# SEARXNG_BASE_URL in this mode too; httpRoute.hostnames is left empty on
+# purpose, so the fallback to ingress.domain is what the test exercises.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/sure.yaml

@@ -0,0 +1,33 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# An overlay and not a change to ci/sure/test-values.yaml: the install-test
+# runs exactly ONE configuration per chart and the two modes are mutually
+# exclusive, so switching the fixture would drop this chart's Ingress from the
+# install for a CRD schema cyberchef's fixture already exercises against the
+# real Gateway-API CRDs.
+#
+# ingress.enabled: false is not optional here - the chart aborts its own render
+# when both modes are true. For THIS chart the combination also exercises
+# sure.publishedOverTls: with the Ingress off and the route on, the render must
+# still produce RAILS_ASSUME_SSL/RAILS_FORCE_SSL as "true", because TLS is
+# terminated at the Gateway. That is not asserted by this test - it only looks
+# at HTTPRoutes - but it is rendered here, so a regression shows up in the
+# manifest this job parses rather than only in a cluster.
+#
+# ingress.domain comes from ci/sure/test-values.yaml and keeps feeding
+# APP_DOMAIN, WEBAUTHN_RP_ID and WEBAUTHN_ALLOWED_ORIGINS in this mode too;
+# httpRoute.hostnames is left empty on purpose, so the fallback to
+# ingress.domain is what the test exercises.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/urlaubsverwaltung.yaml

@@ -0,0 +1,28 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# An overlay and not a change to ci/urlaubsverwaltung/test-values.yaml: the
+# install-test runs exactly ONE configuration per chart and the two modes are
+# mutually exclusive, so switching the fixture would drop this chart's Ingress
+# from the install for a CRD schema cyberchef's fixture already exercises
+# against the real Gateway-API CRDs.
+#
+# ingress.enabled: false is not optional here - the chart aborts its own render
+# when both modes are true.
+#
+# ingress.domain comes from ci/urlaubsverwaltung/test-values.yaml. This is the
+# one chart in the group where nothing but the routing templates reads it, so
+# with the overlay applied the HTTPRoute's required() is the only thing
+# demanding it - which is exactly the path worth rendering.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https

ci/httproute/voucher-vault.yaml

@@ -0,0 +1,29 @@
+# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
+#
+# Its one job is to put this chart into Gateway mode, because the convention
+# ships with httpRoute.enabled: false and the test would otherwise be green
+# over nothing. A chart that has an overlay here and still renders no
+# HTTPRoute FAILS the test - that is the whole point of the file existing.
+#
+# An overlay and not a change to ci/voucher-vault/test-values.yaml: the
+# install-test runs exactly ONE configuration per chart and the two modes are
+# mutually exclusive, so switching the fixture would drop this chart's Ingress
+# from the install for a CRD schema cyberchef's fixture already exercises
+# against the real Gateway-API CRDs.
+#
+# ingress.enabled: false is not optional here - the chart aborts its own render
+# when both modes are true.
+#
+# ingress.domain comes from ci/voucher-vault/test-values.yaml and keeps feeding
+# Django's DOMAIN (and through it ALLOWED_HOSTS) in this mode too;
+# httpRoute.hostnames is left empty on purpose, so the fallback to
+# ingress.domain is what the test exercises - and the two therefore cannot
+# disagree here, which is the one way this chart fails invisibly.
+ingress:
+  enabled: false
+httpRoute:
+  enabled: true
+  parentRefs:
+    - name: public
+      namespace: gateway
+      sectionName: https