fix: pin connection for advisory lock lifecycle

[thetutlage]

Summary

• Advisory locks are session-scoped (bound to the database connection that acquired them), but rawQuery picks a random connection from the pool each time. This causes releaseAdvisoryLock to fail with E_UNABLE_RELEASE_LOCK when it lands on a different connection than getAdvisoryLock.
• When pool max > 1, the migration runner now pins a dedicated connection and passes it to the dialect's lock methods. With pool max = 1, pinning is skipped (unnecessary and would starve other queries).
• Dialect getAdvisoryLock and releaseAdvisoryLock accept an optional connection parameter to use a specific connection instead of acquiring one from the pool.

Closes #1153

Test plan

• Pool of 1: holding a connection starves the pool (proves pinning must be conditional)
• Pool of 2 without pinned connection: release fails (proves the bug)
• Pool of 2 with pinned connection: release succeeds (proves the fix)
• Migration runner with pool of 4: full migration cycle completes
• Migration runner with pool of 1: full migration cycle completes
• All existing migration and query client tests pass