fix(ops): reach the DB via ephemeral psql pod, drop CNPG discovery

[maksymhryzodub-prog]

Evidence from the last run

The diagnostics added in #22 settled the question (run after #22 merge):

• clusters.postgresql.cnpg.io in platform: No resources found
• No ranch-db-* pods; the namespace holds only ranch-api/app/admin, lightrag (+ its own postgres) and browser-pool

So the CNPG cluster from k8s/deploy/10-postgres.yaml / k8s/infrastructure/database/pg-cluster.yaml does not exist in prod — the known ArgoCD sync gap. Terraform's modules/database is a stub deferring to those same manifests. Where the API's database actually lives is unknowable from the repo — but ranch-api is Running, so its DATABASE_URL in the ranch-api-env secret points at the real thing.

Fix

Stop searching for a DB pod entirely:

1. Launch an ephemeral postgres:16-alpine client pod in platform that receives DATABASE_URL via secretKeyRef — the exact connection string the running API uses. It never leaves the cluster and is never printed; the step echoes only the credential-stripped host:port/db part for the log.
2. kubectl exec pipes the same guarded SQL through psql "$DATABASE_URL" — works wherever the DB lives (in-cluster, external, managed).
3. Inputs enter the pod as env vars and reach SQL via \getenv + set_config() — still zero string interpolation.
4. The pod self-expires (activeDeadlineSeconds: 600, sleep 300 command) and an if: always() step deletes it, so nothing lingers even on failure.

Guards unchanged: target must exist, the last remaining Owner can never be demoted, owners printed before/after.

Verification

Next dispatch after merge. If the client pod can't start (image pull, missing secret key), the step dumps kubectl describe of the pod instead of a bare error.

🤖 Generated with Claude Code