fix(operator): TCP keepalives + per-query timeout on operator-side libpq

[passcod]

🤖

Summary

The operator's own `tokio-postgres` clients open raw `TcpStream`s with no keepalives, so a NAT-evicted or silently-dead socket — between reconciles, between queries on the same client, or while a long-running `DROP SCHEMA ... CASCADE` is in flight — wedges that reconcile indefinitely. The Controller keeps processing other replicas, but the stuck one never makes progress (`observedGeneration` falls behind, status fields freeze) until the operator pod is restarted.

Fix

Two complementary safeguards in `postgres.rs`:

1. TCP keepalives on the direct in-cluster path (`connect_via_tcp`). Mirrors the libpq URI keepalives we already use in the schema-migration Job: 60s idle, 10s interval, 3 retries — detects dead sockets within ~90s. Implemented via `socket2::SockRef::from(&stream).set_tcp_keepalive(...)` before handing the stream to `Config::connect_raw`.
2. Per-query timeout (`QUERY_TIMEOUT = 5 min`) wrapping every `query / query_one / query_opt / execute` call, as a backstop for the case where the connection ACKs keepalive probes but the query itself stalls. Generous because `DROP SCHEMA CASCADE` on a populated dbt schema can legitimately take minutes; intent is runaway detection, not a query SLA.

The port-forward path (used out-of-cluster, e.g. CI / dev) goes through the kube API server WebSocket — it has its own keepalive handling, so no socket-level change is meaningful there.

Shape

• New helpers `query_timeout` / `query_one_timeout` / `query_opt_timeout` / `execute_timeout` that wrap the corresponding `tokio_postgres::Client` methods in `tokio::time::timeout`.
• All four operator-side query sites in `postgres.rs` migrated to the timeout helpers.
• New `socket2` direct dependency (already transitive via `hyper-util`).