fix(supabase): kong /healthz service URL — drop self-reference

Follow-up to 23f3f14. With the checksum annotation in place, `helm
upgrade` did start rolling Kong forward, but the new pod never became
Ready: `rollout status` timed out with
  "1 old replicas are pending termination"

Kong's ConfigMap contains the /healthz route correctly, the BackendConfig
is HTTP /healthz, but the Kong process itself refuses to start cleanly
when one of its services has `url: http://127.0.0.1:8000/` -- Kong's own
proxy port. This self-reference apparently trips the declarative-config
parser (undocumented; symptomatic only).

Switch to a RFC-2606 `.invalid` placeholder. The request-termination
plugin short-circuits before any DNS lookup or upstream connection, so
a non-resolvable URL is functionally equivalent and Kong's parser has
nothing to complain about.

Same change in both places we define the /healthz route:
- supabase/helm/knoe-supabase/templates/kong/config.yaml (supabase-kong)
- etc/init_kong.sh inline kong.yml heredoc (knoe-svc-kong)

The knoe-svc-kong backend was already HEALTHY with the self-referential
URL -- different Kong instance, possibly different parser path -- but
keeping the two configs aligned so future edits don't drift.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

etc/init_kong.sh

@@ -382,8 +382,14 @@ services:
   # returns 200 synchronously with no upstream call, so the probe passes as long
   # as the Kong proxy itself is running. GCE rejects \`type: TCP\` in BackendConfig
   # (only HTTP/HTTPS/HTTP2 accepted), so we use this route for HTTP liveness.
+  #
+  # URL is a RFC-2606 reserved \`.invalid\` hostname that never resolves. A
+  # self-referential URL like \`http://127.0.0.1:\${KONG_PROXY_PORT}/\` crashlooped
+  # the supabase-kong pod on startup (Kong's declarative-config parser appears
+  # to reject the self-reference). Since request-termination short-circuits
+  # before any DNS lookup, a non-resolvable placeholder is equivalent.
   - name: healthz
-    url: http://127.0.0.1:${KONG_PROXY_PORT}/
+    url: http://knoe.healthz.invalid/
     routes:
       - name: healthz
         paths:

supabase/helm/knoe-supabase/templates/kong/config.yaml

@@ -55,8 +55,17 @@ data:
       # originally wanted, but using the HTTP protocol that GCE's L7
       # BackendConfig CRD actually accepts (TCP is rejected with
       # `Protocol "TCP" is not valid, must be one of [HTTP,HTTPS,HTTP2]`).
+      #
+      # URL is a RFC-2606 reserved `.invalid` hostname that never resolves.
+      # We originally tried `http://127.0.0.1:8000/` here, which is Kong's
+      # own proxy port -- this crashlooped the pod on startup (rollout timed
+      # out waiting for new pod to become Ready). Suspected cause: Kong's
+      # declarative-config parser rejects the self-reference. Since the
+      # request-termination plugin short-circuits before any DNS lookup or
+      # upstream connection, using a non-resolvable placeholder URL is
+      # equivalent in behavior but avoids the loop detection.
       - name: healthz
-        url: http://127.0.0.1:8000/
+        url: http://knoe.healthz.invalid/
         routes:
           - name: healthz
             strip_path: true