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

rallly/templates/NOTES.txt

@@ -6,11 +6,16 @@
 {{- $service := printf "%s-%s-service" .Release.Name .Chart.Name -}}
 {{- $envNames := list -}}
 {{- range $entry := .Values.rallly.env }}{{- $envNames = append $envNames $entry.name }}{{- end }}
+{{- $httpRoute := .Values.httpRoute | default dict -}}
+{{- $hostnames := $httpRoute.hostnames | default list -}}
+{{- if not $hostnames -}}
+{{- $hostnames = list .Values.ingress.domain -}}
+{{- end -}}
 Rallly {{ .Chart.AppVersion }} — release {{ .Release.Name }} in namespace {{ .Release.Namespace }}.
 
 {{- if .Values.ingress.enabled }}
 
-ACCESS
+ACCESS — INGRESS MODE (ingress.enabled: true, httpRoute.enabled: false)
   https://{{ .Values.ingress.domain }}
 
   The certificate is requested by cert-manager through the "{{ .Values.ingress.clusterIssuer }}"
@@ -18,11 +23,50 @@ ACCESS
   it with
 
     kubectl -n {{ .Release.Namespace }} get certificate tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress
+{{- else if $httpRoute.enabled }}
+
+ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)
+{{- range $hostnames }}
+  https://{{ . }}
+{{- end }}
+
+  This release renders an HTTPRoute ({{ .Release.Name }}-{{ .Chart.Name }}-httproute) and NOTHING else
+  of the routing path — no Gateway, no class, no Certificate. Three things
+  therefore belong to the cluster and not to this chart:
+
+    1. The Gateway-API CRDs. Without them this install would have failed.
+    2. The Gateway named in httpRoute.parentRefs
+{{- range $httpRoute.parentRefs }}
+         {{ .name }}{{ if .namespace }} in namespace {{ .namespace }}{{ end }}{{ if .sectionName }}, listener {{ .sectionName }}{{ end }}
+{{- end }}
+       must exist AND its listener must allow routes from this namespace
+       ({{ .Release.Namespace }}) in allowedRoutes. A rejected attachment shows
+       up only in the route's status:
+
+         kubectl -n {{ .Release.Namespace }} get httproute {{ .Release.Name }}-{{ .Chart.Name }}-httproute -o yaml
+
+       Read status.parents[].conditions — "Accepted: True" and
+       "ResolvedRefs: True" is a working attachment. An empty status means no
+       controller has looked at the route at all.
+    3. The TLS certificate for the hostname, on the Gateway's listener.
+       ingress.clusterIssuer is NOT used in this mode and is not required: the
+       chart renders no Certificate, so there is no
+       tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress secret and nothing for cert-manager to do.
+
+  ingress.annotations is inert in this mode — the Gateway API has no annotation
+  channel — and nothing this chart needs lives there.
+
+  MIND THE HOSTNAME IN THIS MODE. NEXT_PUBLIC_BASE_URL still follows
+  ingress.domain ("https://{{ .Values.ingress.domain }}"), not httpRoute.hostnames, and the OIDC
+  redirect URI registered at the provider is built from it. Publishing under a
+  name that ingress.domain does not carry gives you an instance whose links and
+  sign-in all leave for the other host.
 {{- else }}
 
-ACCESS — NO INGRESS
-  ingress.enabled is false, so this release has no Ingress and no certificate;
-  ingress.clusterIssuer is not needed. ingress.domain still is — see below.
+ACCESS — NEITHER INGRESS NOR HTTPROUTE
+  ingress.enabled and httpRoute.enabled are both false, so this release has no
+  Ingress, no HTTPRoute and no certificate; ingress.clusterIssuer is not
+  needed. ingress.domain still is — see below.
 
     kubectl -n {{ .Release.Namespace }} port-forward svc/{{ $service }} 3000:80
 
@@ -34,7 +78,8 @@ ACCESS — NO INGRESS
 
   ingress.domain is not only the Ingress host. The chart passes it to the app as
   NEXT_PUBLIC_BASE_URL — upstream's "fully qualified public URL of your
-  instance" — which is why it stays required with the Ingress switched off.
+  instance" — which is why it stays required in every mode, with the Ingress
+  switched off and in Gateway mode alike.
 
 SIGN-IN GOES THROUGH THE PROVIDER, AND ONLY THROUGH THE PROVIDER
   This chart sets EMAIL_LOGIN_ENABLED and REGISTRATION_ENABLED to "false" in the
@@ -172,12 +217,18 @@ THE CACHE VOLUME COUNTS AGAINST THE EPHEMERAL-STORAGE LIMIT
   is rebuilt on demand, at the cost of a slower first request.
 
 CHANGING THE DOMAIN LATER IS A CHANGE ON TWO SIDES
-  ingress.domain is the Ingress host, the app's NEXT_PUBLIC_BASE_URL and
+  ingress.domain is the published host, the app's NEXT_PUBLIC_BASE_URL and
   therefore the OIDC redirect URI in one value. Editing it here alone breaks the
   login: the provider refuses a callback it was never told about, and it is the
   provider that reports it — Kubernetes reports a healthy pod{{ if .Values.ingress.enabled }} and a valid
-  certificate for the new name{{ end }}. Register the new redirect URI first, then
-  upgrade.
+  certificate for the new name{{ else if $httpRoute.enabled }} and an accepted
+  route{{ end }}. Register the new redirect URI first, then upgrade.
+{{- if $httpRoute.enabled }}
+  In GATEWAY MODE there is a third side: httpRoute.hostnames, which is what the
+  route actually publishes. It does not follow ingress.domain once set
+  explicitly, so a migration over a second hostname means the provider, the
+  route and ingress.domain all have to end up agreeing.
+{{- end }}
 {{- if $envNames }}
 
 rallly.env ADDS {{ len $envNames }} VARIABLE(S): {{ join ", " $envNames }}
@@ -191,5 +242,5 @@ rallly.env ADDS {{ len $envNames }} VARIABLE(S): {{ join ", " $envNames }}
 SCALED TO ZERO
   {{ if .Values.scaleDown }}scaleDown: true{{ else }}rallly.replicas: 0{{ end }} — the Deployment runs with replicas: 0, so nothing answers
   until you set it back and upgrade again. Secrets and Service{{ if .Values.ingress.enabled }}, and the Ingress
-  with its certificate,{{ end }} stay in place.
+  with its certificate,{{ else if $httpRoute.enabled }}, and the HTTPRoute,{{ end }} stay in place.
 {{- end }}