Transaction Pooler (Supavisor) Hangs On Indexed Queries Due To ClientRead Wait Leak

Supavisor transaction pooler fails to propagate client disconnection/cancellation to the PostgreSQL backend when a client times out or closes the connection mid-transaction. The backend remains in state=active, wait_event=ClientRead, waiting for the next client message, and the connection is never returned to the pool. Statement_timeout does not fire because the query itself has completed; the hang occurs after execution while awaiting protocol-level messages (e.g., extended query protocol Sync). This is a pooler lifecycle bug, not a database indexing or query performance issue.

1. Connect to the Supabase project using the transaction pooler connection string (host `jtctezujqbzwgcsufqsj.supabase.co`, port 6543). 2. Execute a trivial indexed SELECT (e.g., `SELECT created_at FROM users WHERE ...`) that returns ~12 rows and completes in ~230ms through the direct/session pooler. 3. Observe that through the transaction pooler the query intermittently does not return; in `pg_stat_activity` the backend shows `state=active`, `wait_event_type=Client`, `wait_event=ClientRead` for 5+ minutes. 4. The client application times out after 300 seconds with no error returned, and the backend connection is not released back to the pool.

Session/direct pooling holds a dedicated backend connection per client, increasing total database connections. Under high concurrency this can exhaust `max_connections` and cause connection errors. This hotfix is a workaround, not a permanent fix. Rollback: once Supavisor is patched/upgraded, revert `DATABASE_URL` to the transaction pooler (port 6543) and remove the SQL timeout overrides if they interfere with long-running legitimate queries.