fix(operator): drop wall-clock query timeout, keep TCP keepalives

[passcod]

🤖

Summary

Follow-up to #55. The per-query 5-minute `tokio::time::timeout` introduced alongside TCP keepalives turned out to be too tight for a legitimately slow statement: `DROP SCHEMA dbt CASCADE` on a populated dbt schema runs for tens of minutes. With the timeout in place, every retry hits the same wall and the reconcile loop never converges — worse than the original wedge it was meant to mitigate.

Why keepalives alone are enough

The original failure mode was a NAT-evicted (or otherwise silently-dead) socket: the operator's tokio task waits for a server reply that will never come. TCP keepalives fire on the kernel's own timer regardless of in-flight application traffic, so:

• A legitimately long `DROP SCHEMA … CASCADE` keeps working — the socket is healthy, keepalive probes get ACKed.
• A dead socket fails the keepalive probe and the kernel reports the socket dead within ~90s; the query returns an error and the reconcile retries.

So the wall-clock timeout is unnecessary and actively harmful.

Shape

• Remove `QUERY_TIMEOUT`, `query_timeout`, `query_one_timeout`, `query_opt_timeout`, `execute_timeout` from `postgres.rs`.
• Revert the four call sites to direct `tokio_postgres::Client` methods.
• Keep `set_tcp_keepalive` and the keepalive constants — these are the actual fix.
• Add a `Lessons learned` section to `AGENTS.md` recording the keepalives-vs-wall-clock-timeout reasoning so the next iteration doesn't re-add the timeout.