fix(supabase): chart cleanups exposed during live helm upgrade

Two follow-ups to commit c3fae73 (queue #15) surfaced when applying
the DASHBOARD removal to live `supabase` release on knoe-dev-0:

1. **Delete `templates/test/kong.yaml`.** This was a Helm Test Job that
   validated the Studio dashboard's basic-auth gate. The basic-auth
   plugin was retired in commit 25f1b2e (oauth2-proxy fronting); the
   consumer + credentials in commit c3fae73. The test has nothing
   left to test — it referenced `supabase.secret.dashboard` template
   (gone) and `.Values.secret.dashboard.{secretRef,secretRefKey}`
   (gone), causing `helm template`/`upgrade` to fail. Removing the
   file is the right move; if dashboard auth ever comes back as
   something else, write a fresh test for that.

2. **Add `secret.oauth2proxy` + clarify `deployment.oauth2proxy`
   defaults in values.yaml.** The chart has
   `templates/studio/oauth2proxy-{deployment,service}.yaml` and
   `templates/secrets/oauth2proxy.yaml` (Junie's Phase 2 OIDC adds)
   guarded by `if .Values.deployment.oauth2proxy.enabled`. The guard
   short-circuits when the parent map exists, but if the map itself
   is undefined helm fails with `nil pointer evaluating interface{}.enabled`.

   Added a `secret.oauth2proxy` block (empty defaults) so the secrets
   template guard can evaluate cleanly. `deployment.oauth2proxy.enabled`
   was already `false` in values.yaml; added a comment explaining the
   chart oauth2-proxy templates are vestigial — the deployed
   oauth2-proxy lives in `deploy/gcp/gke/oauth2-proxy-deployment.yaml`,
   in FRONT of supabase-kong (commit 25f1b2e), not as a Kong upstream.

Live state after this commit:
  - `helm upgrade supabase ./supabase/helm/knoe-supabase
     --reset-then-reuse-values` succeeds.
  - revision 3 deployed; configmap field manager = `helm` (sole owner).
  - `kubectl get cm supabase-kong -o yaml | grep DASHBOARD` returns 0
    matches.
  - All Kong env vars on the new pod are clean (no DASHBOARD_*).
  - External smoke tests:
      /onboard.html → 200
      /rest/v1/ no auth → 401
      / (Studio gate) → 302 to Google
      /healthz → 302
      svc.knoe.dev/grafana/login → 200
  - cnpg-grafana panels still populate (PodMonitor migration verified
    earlier in same session: 3 postgres exporter targets up; cluster
    label injection working).

Side-finding handled live: nodes lacked the new
`knoe.dev/node-role=general` label that Junie's chart defaults to in
nodeAffinity. Added the label to all 3 knoe-dev-0 nodes alongside the
legacy `prole.org/node-role=general`. The label rename has been
tracked in CLAUDE.md as a follow-up; this is partial closure for the
app cluster (DB cluster nodes still need the same treatment when next
relevant).

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

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

@@ -1,50 +0,0 @@
-{{- if .Values.deployment.kong.enabled -}}
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: {{ include "supabase.fullname" . }}-test-kong
-  labels:
-    {{- include "supabase.labels" . | nindent 4 }}
-  annotations:
-    "helm.sh/hook": test
-spec:
-  ttlSecondsAfterFinished: 100
-  template:
-    spec:
-      containers:
-        - env:
-            - name: DASHBOARD_USERNAME
-              valueFrom:
-                secretKeyRef:
-                  {{- if .Values.secret.dashboard.secretRef }}
-                  name: {{ .Values.secret.dashboard.secretRef }}
-                  key: {{ .Values.secret.dashboard.secretRefKey.username | default "username" }}
-                  {{- else }}
-                  name: {{ include "supabase.secret.dashboard" . }}
-                  key: username
-                  {{- end }}
-            - name: DASHBOARD_PASSWORD
-              valueFrom:
-                secretKeyRef:
-                  {{- if .Values.secret.dashboard.secretRef }}
-                  name: {{ .Values.secret.dashboard.secretRef }}
-                  key: {{ .Values.secret.dashboard.secretRefKey.password | default "password" }}
-                  {{- else }}
-                  name: {{ include "supabase.secret.dashboard" . }}
-                  key: password
-                  {{- end }}
-          name: test-kong
-          image: kdevup/curljq
-          imagePullPolicy: IfNotPresent
-          command:
-            - /bin/bash
-            - -c
-            - |
-              echo "Attempting to access dashboard with provided credentials..."
-              curl -sL --fail \
-                -o /dev/null \
-                "http://${DASHBOARD_USERNAME}:${DASHBOARD_PASSWORD}@{{ include "supabase.kong.fullname" . }}:{{ .Values.service.kong.port }}" \
-                || ( echo -e "\e[0;31mFailed to get a valid response." && exit 1 )
-              echo "Successfully connected."
-      restartPolicy: Never
-{{- end }}

supabase/helm/knoe-supabase/values.yaml

@@ -114,6 +114,23 @@ secret:
     # secretRefKey:
     #   apiKey: apiKey
 
+  ## oauth2-proxy credentials. **Defaults present only to satisfy template
+  ## guards in `templates/studio/oauth2proxy-{deployment,service}.yaml` and
+  ## `templates/secrets/oauth2proxy.yaml`.**
+  ##
+  ## The deployed oauth2-proxy runs OUTSIDE this chart at
+  ## `deploy/gcp/gke/oauth2-proxy-deployment.yaml` (in FRONT of supabase-kong,
+  ## not as a Kong upstream). The chart templates here reflect an alternate
+  ## architecture that was never deployed; gating `deployment.oauth2proxy.enabled`
+  ## off keeps them dormant. If a fresh deploy of THIS chart's oauth2-proxy
+  ## flavour is ever wanted, populate these values + flip enabled true.
+  oauth2proxy:
+    secretRef: ""
+    secretRefKey: {}
+    clientId: ""
+    clientSecret: ""
+    cookieSecret: ""
+
   ## S3-compatible credentials
   ##
   s3: