Runs one check's queries under server-side safety limits.

• Postgres: one transaction per check. Its first statement is

  SELECT set_config('transaction_read_only', 'on', true),
         set_config('statement_timeout', $1, true),
         set_config('lock_timeout', $2, true),
         set_config('idle_in_transaction_session_timeout', $3, true)

  (transaction_read_only only when read_only: true). All settings are transaction-local. The transaction is always rolled back, never committed. Because the settings would otherwise leak into a caller's transaction, calling QueueKeeperCheck.run/2 inside an open transaction is refused.

• MySQL: the connection is checked out for the duration of the check, max_execution_time (which applies to SELECT only) is set for the session and restored to its previous value afterwards. If the process dies mid-check, DBConnection disconnects that connection, so the setting cannot leak back into the pool. Read-only enforcement on MySQL comes from the database grants (see docs/SECURITY_REVIEW.md).

• SQLite: no server-side settings exist; only the client-side timeout applies.

Every engine also gets a client-side :timeout of statement_timeout + 2000 ms on each query, so a query that the server does not cancel is abandoned by the client, and on Postgres and MySQL the whole check (one transaction / checkout) is limited to check_timeout ms.