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

.github/workflows/validate-charts.yml

@@ -203,6 +203,40 @@ jobs:
       - name: "Check every rendered selector against the rendered pod labels"
         run: ci/run-selector-match-test.sh
 
+  httproute-match:
+    name: "HTTPRoute match"
+    runs-on: ubuntu-latest
+    # The third job that ignores the changed-chart matrix and runs over *every*
+    # chart (Gitea #114), and for the same reason as the two above: the mistake
+    # arrives by copy into a chart whose own diff nobody reads for it - and this
+    # convention is about to be copied into 20 more charts when the sweep runs.
+    #
+    # What it asserts: every HTTPRoute a chart renders names a Service, on a
+    # port, that the SAME render creates, and its parentRefs is not empty. Both
+    # failures are SILENT and neither is reachable from the other checks:
+    # parentRefs: [] attaches the route to no Gateway (created, schema-valid,
+    # routes nothing, no event and no condition), and a backendRef is resolved
+    # by name with nothing validating that the name exists. The real Gateway-API
+    # CRDs in the install-test prove the object is WELL-FORMED; they accept both
+    # of these, because an empty list and a dangling name are valid YAML
+    # against that schema.
+    #
+    # What is NOT provable anywhere, and is written down rather than implied: no
+    # Gateway controller runs in CI, so no route is ever reconciled. That
+    # traffic flows is not part of this pipeline's claims.
+    #
+    # No cluster and no Trivy; ~3 seconds for the whole repository, depends on
+    # no other job. The YAML is parsed by Helm through ci/yaml2json, because the
+    # runners have neither pyyaml nor yq and a hand-written parser could read
+    # nothing and report nothing - see the script's header.
+    steps:
+      - name: "Checkout Repository"
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - name: "Install Helm"
+        uses: azure/setup-helm@9bc31f4ebc9c6b171d7bfbaa5d006ae7abdb4310 # v5
+      - name: "Check every rendered HTTPRoute against the rendered Services"
+        run: ci/run-httproute-match-test.sh
+
   trivy-config:
     name: "Trivy config ${{ matrix.chart }}"
     needs: detect-changed-charts