feat(cyberchef): Gateway-API as an alternative to the Ingress (pilot)

The Gateway-API pilot of Gitea #114: one chart, the convention, the CI that
holds it. The remaining 20 charts follow in their own PRs.

The form, additive and off by default:

    httpRoute:
      enabled: false     # counterpart to ingress.enabled
      parentRefs: []     # the Gateway - a platform object
      hostnames: []      # empty = [ingress.domain]

Only HTTPRoute with parentRefs is rendered: no Gateway, no gatewayClassName,
no Certificate, and no implementation-specific policy object. That subset is
identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is
what lets the implementation be chosen later without touching the charts
again. Class and certificate move to the platform.

Four guards, all against silent failures:

  - mutually exclusive with ingress.enabled, with a render abort naming BOTH
    value paths. A migration runs over a second hostname, not in parallel.
  - parentRefs mandatory in Gateway mode, render abort on the empty list: a
    route without a parent is created, is schema-valid, and routes nothing.
  - hostnames empty means [ingress.domain], so the hostname has one source.
  - the mode is a VALUE, not auto-detection: .Capabilities.APIVersions is
    unreliable at template time and a missing CRD fails at install time.

ingress.clusterIssuer was already only read inside the Ingress template, so
the "conditionally required" half of #114 needed no change in this chart -
checked rather than assumed, and it has to be re-checked per chart in the
sweep.

CI, both halves, because neither covers the other:

  - the install-test installs cyberchef in GATEWAY mode against the REAL
    Gateway-API CRDs (standard channel v1.6.3, pinned and Renovate-tracked,
    applied --server-side). A schema-less stub would accept a malformed route
    and prove only that something was created. The Ingress path of this one
    chart is no longer installed; it is a built-in type that never routed in
    k3d anyway, and helm lint renders this chart's defaults - Ingress mode -
    on every PR.
  - ci/run-httproute-match-test.sh, over every chart on every PR: every
    backendRefs entry must name a Service, on a port, that the SAME render
    creates, and parentRefs must not be empty. The CRDs accept both of those
    mistakes, so the schema cannot catch them, and the only report would be a
    route status no controller writes in CI.

What stays unprovable, and is written down instead of implied: that traffic
flows. No Gateway controller runs in k3d.

Minor: additive with unchanged defaults, proven by an empty helm template
diff against origin/main for the default values.

Part of #114

ci/run-install-test.sh

@@ -8,6 +8,8 @@
 #
 # Layout (repo root):
 #   ci/common/            fixtures applied for every chart (OnePasswordItem stub CRD)
+#   ci/gateway-api-crds.sh        the REAL Gateway-API CRDs, applied only for a
+#                                 chart whose render contains an HTTPRoute
 #   ci/<chart>/test-values.yaml   values for the CI install (required)
 #   ci/<chart>/fixtures.yaml      dummy secrets / throwaway infra / static PVs (optional)
 #   ci/<chart>/fixtures.env.yaml  fixtures with ${VARS} filled in from the environment (optional)
@@ -199,6 +201,28 @@ echo "::endgroup::"
 # chart whose declared dependencies are not in charts/. No-op for a chart
 # without dependencies; see ci/helm-dependencies.sh.
 "$ROOT/ci/helm-dependencies.sh" "$ROOT/$CHART"
+
+# --- 3a. Gateway-API CRDs, for a chart whose CI values render a route --------
+# Detected from the render rather than declared per chart in settings.env, for
+# the same reason the render tests run over every chart: there is then no list
+# to maintain, and the sweep of Gitea #114 enrols a chart by switching its
+# fixture into Gateway mode. The CRDs are REAL and not a stub - with a
+# schema-less stub the API server would accept a malformed HTTPRoute and the
+# install-test would prove only that something was created; see
+# ci/gateway-api-crds.sh for the whole argument, and for why they are not in
+# ci/common/ (which is applied client-side for every chart).
+#
+# A grep on the rendered kind, and a false negative here is loud rather than
+# silent: without the CRDs the helm install below fails with "no matches for
+# kind HTTPRoute in version gateway.networking.k8s.io/v1", which names exactly
+# what is missing.
+if helm template "$RELEASE" "$ROOT/$CHART" -f "$CI_DIR/$CHART/test-values.yaml" \
+    | grep -q '^kind: HTTPRoute$'; then
+  echo "::group::Gateway API CRDs"
+  "$ROOT/ci/gateway-api-crds.sh"
+  echo "::endgroup::"
+fi
+
 echo "::group::helm install"
 helm install "$RELEASE" "$ROOT/$CHART" \
   --namespace "$NAMESPACE" \