fix: treat io.ErrUnexpectedEOF as driver.ErrBadConn to prevent connection pool poisoning

[henhouse]

Fixes #1298

When a TCP read is interrupted mid-message (partial DataRow), pq's recvMessage returns io.ErrUnexpectedEOF. Prior to this fix, handleError did not classify this as driver.ErrBadConn, so:

1. cn.err was never set, and IsValid() returned true
2. The inProgress atomic flag remained stuck at true (since ReadyForQuery
   never arrived)
3. database/sql kept handing out the broken connection
4. The CompareAndSwap guard rejected every subsequent query with
   "there is already a query being processed on this connection"

This is especially impactful with CockroachDB, where node drains and rebalances routinely produce partial reads.

Two changes:

1. error.go: Treat io.ErrUnexpectedEOF the same as io.EOF in handleError - both indicate a dead connection.
2. conn.go: Wrap errQueryInProgress with driver.ErrBadConn so database/sql evicts the connection instead of recycling it. This acts as defense for any future code path that leaves inProgress stuck.

Includes unit test for handleError and integration test using a TCP fault-injection proxy that truncates a DataRow mid-body to reproduce the exact failure mode.

[arp242]

Can't this use the existing pqtest.Fake to test this error? Over 250 lines of code for a single test is quite a lot to maintain going forward, and it's not immediately obvious what it does exactly either.

I'm also okay with just running this against a real database. I made #1304 to run it in the CI, although I need to finish up some bits.

Is changing errQueryInProgress intentional or a left-over from some previous debugging?

[henhouse]

@arp242 Oops yeah that was left behind, thanks.

Pushed an update that uses pqtest instead which reduces it a lot. If you'd prefer not having a test for this case entirely, I can just remove it. It was mostly to provide a in-repo example of the demo I linked to that reproduces the case in full. The check in error_test.go is minimally sufficient to check for a regression in this case.

[arp242]

Thanks!