`PooledReader` lease is bricked by one SQL error, and a healthy pooled connection is dropped

src/questdb/egress.pxi:587 arms _must_close = True before crossing the
network, and no error path clears it. On a plain QUERY_ERROR the cursor was
created fine and the error surfaces from the first batch fetch, so the lease is
refused from then on and a healthy pooled connection is discarded.

Reproduced against QuestDB 10.0.1: the pool goes (0, 1) → (0, 0) after one
bad query, and the next lease.query reports that the transport was torn
down — which it was not.

The Rust side agrees that the connection is still good:
reader.rs:2058-2105 handles ServerEvent::Error without
terminate_with_close(), and Cursor::connection_reusable() returns true
for exactly this case.

Fix sketch. Consult connection_reusable() on the error paths, the way
QueryResult.cancel() already does. The FFI is already declared at
src/questdb/line_sender.pxd:1480, so this is a client-side change with no
upstream dependency.

Pre-existing, from #130. Found during the PR #140 review sequence; recorded
there rather than widening that branch.

Start at src/questdb/egress.pxi:587 and trace the error paths that arm _must_close; compare them with QueryResult.cancel() and the FFI declaration at src/questdb/line_sender.pxd:1480. Use reader.rs:2058-2105 and Cursor.connection_reusable() to confirm the QUERY_ERROR case remains reusable. Done means a bad query does not brick the lease or discard the healthy pooled connection, and the next lease.query still works.