feat(rds): transparent stale-connection reconnect in RdsServiceGateway

[Kydoimos97]

New Features

• RdsServiceGateway now recovers a stale database connection automatically. In single-connection mode the gateway opened one psycopg2 connection at init and reused it for the life of the process with no liveness check or reconnect. A long-running consumer (e.g. a pipeline whose connection sat idle across a long compute phase) would have that connection dropped server-side, and the next get_data/update_database failed with connection already closed. Callers now get transparent recovery: on a connection-level error the gateway reconnects and retries the operation once.

Fixes

• Dead-connection rollback no longer masks the real error. The except blocks called conn.rollback(), which itself raises on a dead socket and hid the original failure. Those rollbacks are now guarded against OperationalError/InterfaceError.

Behavior / safety

• Only psycopg2.OperationalError/InterfaceError (or messages like "connection already closed", "server closed the connection", "ssl connection has been closed", "connection not open", "terminating connection") trigger the reconnect+retry. Every other psycopg2.Error (IntegrityError, DataError, ProgrammingError, …) keeps its exact prior behavior — no retry.
• The happy path and the raise_on_error semantics are unchanged for non-connection errors.
• Retry is duplicate-safe: every update_database path performs all work then commits once at the very end, so a connection-level failure means nothing was committed and re-running the operation cannot double-write.
• reconnect() rebuilds the single connection (or the pool) from the existing db_uri; it is a no-op in test mode.

Testing

• tests/test_connect.py: 160 passed, ruff clean. New tests cover reconnect (single mode + test-mode no-op), connection-error classification, get_data reconnect-and-retry-once, and IntegrityError NOT triggering a reconnect for both get_data and update_database.

Context

• Root cause of prod incident IR-1916 (ai-pipeline discarded a fully-trained model when its long-held RDS connection went stale before the final write). ai-pipeline shipped an app-layer guard already; this puts the fix in the shared library so every WrenchCL consumer inherits it. Ship as 6.3.0.

End-user impact

No user-facing surface. Operationally: services using RdsServiceGateway across long-lived processes stop failing on transient/idle connection drops.