Use get_result instead of execute for pool connection ping

[DhineshKrishnan1206]

Summary

• Changes the Verified recycling method's ping from .execute() to .get_result::<i32>() so the response row is actually read back from the server
• This detects connections with corrupt internal read buffers that silently pass .execute() (which only reads the row count) but fail on real queries with "Unexpected end of row" / "buf doesn't have enough data" errors
• Updates the corresponding trait bounds from ExecuteDsl to LoadQuery across all pool backends (bb8, deadpool, mobc) and the r2d2 connection wrapper

Fixes #139

Context

As discussed in #139, the current ping uses .execute("SELECT 1") which sends the query and reads the affected row count, but never reads actual row data. A connection whose read buffer contains leftover bytes from a previous partially-consumed response will pass this check, get returned to the pool, and then fail on the next real query.

Using .get_result::<i32>() forces the connection to deserialize a row, which will surface buffer corruption immediately during the health check rather than on a subsequent application query.

Test plan

• cargo check --features "postgres bb8 deadpool mobc r2d2" — compiles cleanly
• cargo check --features "mysql bb8 deadpool mobc" — compiles cleanly
• cargo check --features "sqlite bb8 deadpool mobc r2d2" — compiles cleanly

[weiznich]

Looks good, thanks for submitting ❤️

This can be merged after a rebase on top of #293 as that one contains the fix for the failing CI job. I will take care of this later today.