[shinzui]

This is the third fix, and it involves an API behavior change I'd appreciate your feedback on. While testing a connection pool with bounded readiness checks, I encountered problems with cancellation and failed-connection disposal.

withConnection reconnects inside its exception handler, including after a timeout. Cleanup can therefore enter another connection attempt and authentication. If reconnection throws, the connection-state MVar remains empty, so later operations can wait indefinitely. Failed or cancelled initialization/authentication can also leave sockets open, and I couldn't find a public close operation for pool disposal.

This proposes closing and invalidating failed handles instead of reconnecting during exception cleanup. It also releases resources when initialization fails and exports an idempotent closeConnection. Subsequent operations raise ConnectionClosed; callers must open a fresh handle to retry. The existing error-test example has been updated accordingly. closeConnection waits for active operations, so owners should stop concurrent use before disposal.

The connection-lifecycle-regressions suite passes on GHC 9.12.4, covering initialization/authentication failures, cancellation, repeated close, invalidated-handle reuse, and a throwing close callback. It uses real allocated sockets with scripted IO. The updated t004-errors executable also builds. I haven't run the full compiler matrix or live-server suite for this branch.

Would explicit reopening fit the intended API? If automatic recovery should be preserved, I'm happy to discuss an alternative that keeps reconnection out of cancellation cleanup.