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

Group 2 of the #114 sweep: the charts whose behaviour hangs off an nginx
annotation - calibre-web-automated, outline, paperless-ngx, zipline
(proxy-body-size) and freesailarr (rewrite-target).

Each gets the form the pilot (cyberchef, PR #115) fixed and group 1 (PR #116)
repeated: an httpRoute block 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 all five.

The upload limit is DOCUMENTED, not rebuilt (decision 2 of the issue). The
Gateway API knows no body size; a policy object would bind the chart to one
implementation. So the Gateway branch of NOTES.txt says, per chart and in the
chart's own terms, that the value is NOT ENFORCED and names where to set it: an
e-book library (calibre), an upload service (zipline), the web-UI half of the
document intake while the consume directory keeps no limit at all (paperless),
and the open #12 pair (outline).

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

  freesailarr gated freesailarr.sharedIngressApps on ingress.enabled, and that
  list is read by the <APP>__SERVER__URLBASE variables as well as by the routing
  objects. In Gateway mode it would have come out EMPTY while the route served
  radarr, sonarr and prowlarr under their prefixes: UrlBase unset, assets and API
  calls linked at the host root, broken UI behind a Ready pod. The helper's two
  guards (seerr/mediathekarr only at "/", no duplicate paths) would have gone
  unenforced there too. Fixed with freesailarr.published (ingress.enabled OR
  httpRoute.enabled) - the same shape as sure.publishedOverTls in group 1, and
  identical to ingress.enabled while httpRoute.enabled is false. Measured: on
  origin/main with ingress.enabled: false the render emits ZERO URLBASE
  variables; with this change in Gateway mode it emits three.

  paperless-ngx was the last chart in the repository rendering its Ingress
  UNCONDITIONALLY. Without an ingress.enabled switch there is no second value
  path for the mutual-exclusion abort to name, and the Ingress plus its
  unconditional required() on clusterIssuer would have kept rendering in Gateway
  mode - a value demanded for nothing, which is issue #114's "Folge 1" and
  README guideline 12. The switch was added, defaulting to true, so the render is
  unchanged.

  paperless-ngx PAPERLESS_URL had no required() of its own: it relied on the
  Ingress template's, which stops firing the moment the Ingress is switchable.
  With httpRoute.hostnames set and ingress.domain empty it would have rendered
  "https://" and refused every login POST as a CSRF failure. It now carries its
  own required(), naming what the value is for.

  calibre-web-automated claimed, in values.yaml and in its schema, that
  ingress.domain is read nowhere but in the Ingress template. The HTTPRoute reads
  it, so the claim now holds only while both modes are off. Corrected rather than
  left standing - the same correction garage needed in group 1.

freesailarr is where the Gateway API is LESS machinery than what it replaces,
not a translation of it. rewrite-target applies per Ingress OBJECT, so
qBittorrent (no base path, prefix must be stripped) needed a second Ingress on
the shared host, which then had to repeat the first object's TLS secret name,
omit the cert-manager annotation conditionally so only one Certificate is
requested, and match an ImplementationSpecific regex path for the rewrite's
capture group. A URLRewrite filter applies per RULE: one route, one rule per
app, the filter on qBittorrent's rule, a plain PathPrefix. All four crutches
gone. It is also the only chart without httpRoute.hostnames - it has no
ingress.domain either, and a chart-global hostname list could not say which of
the ten apps it belonged to, so the hostnames stay in ingress.host and
<app>.ingress.host.

CI: one render overlay per chart under ci/httproute/, so the assertion is not
vacuum-green - ci/run-httproute-match-test.sh goes from 20 held assertions over
10 charts to 36 over 15. freesailarr's overlay moves bazarr onto a host of its
own, so the shared-host route AND the per-app route are both rendered; without
that the per-app branch would be exercised by nothing. 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 paperless-ngx
that fixture is the only install of the valkey-subchart path anywhere.

README also carries a stale figure fixed here: the HTTPRoute test was still
documented at the pilot's 4 assertions over 2 charts, although group 1 had taken
it to 20 over 10.

Not proven, by construction: that traffic flows. No Gateway controller runs in
CI. Not run locally either: k3d, Docker, Trivy. The Gateway branch of NOTES.txt
is EXECUTED by the render test (a template error in it fails the job, verified)
but its text is printed by no pipeline stage - helm template does not emit
notes, and the install-test installs in Ingress mode.

Part of #114

freesailarr/templates/NOTES.txt

@@ -10,6 +10,8 @@
 {{- $shared := include "freesailarr.sharedIngressApps" . | fromJsonArray -}}
 {{- $sharedNames := list -}}
 {{- range $shared }}{{ $sharedNames = append $sharedNames .name }}{{ end -}}
+{{- $httpRoute := .Values.httpRoute | default dict -}}
+{{- $published := include "freesailarr.published" . -}}
 freesailarr — release {{ .Release.Name }} in namespace {{ .Release.Namespace }}.
 {{ if .Values.mediathekarr.enabled }}Ten{{ else }}Nine{{ end }} containers in ONE pod, sharing gluetun's network namespace.
 
@@ -44,7 +46,12 @@ SET gluetun.vpn.firewallOutboundSubnets — IT IS EMPTY RIGHT NOW
 {{- end }}
 
 ACCESS
-{{- if and .Values.ingress.enabled $ingressApps }}
+{{- if and $published $ingressApps }}
+{{- if .Values.ingress.enabled }}
+  INGRESS MODE (ingress.enabled: true, httpRoute.enabled: false)
+{{- else }}
+  GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)
+{{- end }}
 {{- range $shared }}
   {{ .name }}: https://{{ $sharedHost }}{{ if ne .path "/" }}{{ .path }}{{ end }}
 {{- end }}
@@ -56,7 +63,8 @@ ACCESS
 {{- end }}
 {{- if $shared }}
 
-  These apps share one host, one Ingress and one certificate.
+  These apps share one host{{ if .Values.ingress.enabled }}, one Ingress and one certificate{{ else }} and one HTTPRoute ({{ $name }}-httproute), one
+  rule each{{ end }}.
 {{- if has "bazarr" $sharedNames }}
 
   BAZARR NEEDS ONE MANUAL STEP UNDER A SUB-PATH
@@ -73,8 +81,17 @@ ACCESS
 {{- if has "qbittorrent" $sharedNames }}
 
   QBITTORRENT SITS BEHIND A PREFIX-STRIPPING REWRITE
-    It has no base path of its own, so it gets a second Ingress object on the
-    same host whose rewrite cuts the prefix off. Two things there look exactly
+    It has no base path of its own, so the prefix has to be cut off before the
+    request reaches it.
+    {{- if .Values.ingress.enabled }} Under an Ingress that costs a SECOND object on the
+    same host, because nginx applies rewrite-target per object and the other
+    apps must not be rewritten.
+    {{- else }} In Gateway mode that second object is gone: a
+    URLRewrite filter belongs to a RULE, so qBittorrent is one rule of
+    {{ $name }}-httproute with the filter on it and its neighbours are
+    untouched by construction — no extra object, no regex path.
+    {{- end }}
+    Two things here look exactly
     like a login failure and send you looking in the wrong place: its session
     cookie is marked "Secure" (over plain HTTP the browser never sends it back
     and every click bounces to the login form), and it bans the client IP for a
@@ -90,12 +107,48 @@ ACCESS
 {{- end }}
 {{- end }}
 
+{{- if .Values.ingress.enabled }}
   Every app listed with a host of its own has its OWN Ingress and its own TLS
   secret. While cert-manager is still issuing, the browser warns:
 
     kubectl -n {{ .Release.Namespace }} get certificate
 {{- else }}
-  No Ingress is rendered{{ if not .Values.ingress.enabled }} (ingress.enabled is false){{ end }}. Reach an app through its own service:
+  Every app listed with a host of its own has its OWN HTTPRoute
+  ({{ $name }}-<app>-httproute).
+
+  THREE THINGS BELONG TO THE CLUSTER AND NOT TO THIS CHART IN THIS MODE, and if
+  any is missing the addresses above do not answer:
+
+    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. Every route of this release
+       attaches to that same parent. A rejected attachment shows up only in a
+       route's status:
+
+         kubectl -n {{ .Release.Namespace }} get 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 certificates for these hostnames, on the Gateway's listener.
+       ingress.clusterIssuer is NOT used in this mode and is not required, and
+       neither are ingress.className or the per-app overrides of either: the
+       chart renders no Certificate and no class, so there are no
+       tls-{{ $name }}-* secrets and nothing for cert-manager to do.
+
+  ingress.annotations HAS NO COUNTERPART HERE, per-app overrides included: the
+  Gateway API has no annotation channel. The chart needs nothing from it —
+  qBittorrent's rewrite is a filter in this mode — but an annotation you added
+  yourself is gone without a word. A body-size cap for qBittorrent's
+  torrent-file uploads is the likely one; set it at the Gateway or through its
+  implementation's own policy object.
+{{- end }}
+{{- else }}
+  Nothing is published{{ if and (not .Values.ingress.enabled) (not $httpRoute.enabled) }} — ingress.enabled and httpRoute.enabled are both false{{ else if not $ingressApps }} — no enabled app carries <app>.ingress.enabled: true{{ end }}. Reach an app through its own service:
 {{- range $portApps }}
 
     kubectl -n {{ $.Release.Namespace }} port-forward svc/{{ $name }}-{{ .name }}-service {{ .port }}:{{ .port }}
@@ -105,7 +158,8 @@ ACCESS
 
   qBittorrent's WebUI rejects a Host header whose port differs from its own
   ({{ "8080" }}) with a plain 401. A port-forward on a different local port therefore
-  looks like a login failure — forward 8080:8080, or go through the ingress.
+  looks like a login failure — forward 8080:8080, or go through the published
+  address above.
 {{- if .Values.qbittorrent.savePath }}
 
 QBITTORRENT DOWNLOADS GO TO {{ .Values.qbittorrent.savePath }}
@@ -158,8 +212,8 @@ MEDIATHEKARR: TWO PORTS, AND THE SABNZBD API IS NOT AT /api
   back as the SABnzbd complete_dir. Any deviation — a remote path mapping, a
   different mount — imports NOTHING, without an error.
 
-  The UI (setup wizard and download queue) has no ingress{{ if and .Values.mediathekarr.ingress.enabled .Values.mediathekarr.ingress.host }}, other than the one
-  you gave it on {{ .Values.mediathekarr.ingress.host }}{{ end }}:
+  The UI (setup wizard and download queue) is not published{{ if and .Values.mediathekarr.ingress.enabled .Values.mediathekarr.ingress.host }}, other than on the
+  host you gave it, {{ .Values.mediathekarr.ingress.host }}{{ end }}:
 
     kubectl -n {{ .Release.Namespace }} port-forward svc/{{ $name }}-mediathekarr-service 5007:5007
 {{- if $gate.enabled }}
@@ -286,7 +340,7 @@ THE MEDIA CLAIMS ARE YOURS, THE CONFIG VOLUMES ARE THE CHART'S
 
 SCALED TO ZERO
   {{ if .Values.scaleDown }}scaleDown: true{{ else }}replicas: 0{{ end }} — the StatefulSet runs with replicas: 0. PVCs, secrets,
-  services{{ if .Values.ingress.enabled }} and ingresses{{ end }} stay in place; set it back and upgrade to bring the
+  services{{ if .Values.ingress.enabled }} and ingresses{{ else if $httpRoute.enabled }} and HTTPRoutes{{ end }} stay in place; set it back and upgrade to bring the
   stack up again.
 {{- else if ne $replicas "1" }}