SQL queries time out; readiness follows the data store

Cluster rehearsal 3: with PostgreSQL paused (docker pause, so its
kernel still answered TCP keepalives), requests on connections already
checked out hung until it came back, and /healthz/ready stayed 200
through the outage. #41 bounded getting a connection, not using one.

Client-side query limits (store::backend::query_timeout). Every
operation on a PostgreSQL or MySQL connection now runs under a time
limit. A server-side statement_timeout (or MySQL's MAX_EXECUTION_TIME,
which covers SELECTs only) can't do this: the server that would enforce
it is the one not answering. When an operation runs out, its connection
is closed instead of pooled, since a query may still be in flight on it
or a transaction open: deadpool's Object::take on PostgreSQL;
Conn::disconnect on MySQL, which marks the connection closed before it
sends anything, so the pool discards it even when the server never
answers.

- query, 2 minutes: reads, writes (the whole transaction with its
  retries), blobs, SQL lookups, search queries and indexing. These take
  milliseconds; two minutes leaves room for a large blob over a slow
  link and still ends a hang.
- maintenance, 30 minutes: range deletes (account removal, purges),
  unindexing, purge_store, and creating tables and indexes at startup,
  which can legitimately run long in one statement. Their existing
  chunked fallback for server-side statement timeouts is unchanged.
- iterate (exports, reindexing, maintenance scans) can run for hours,
  so the query limit bounds each wait for the database (preparing, the
  query starting, the next row) rather than the whole scan.

The limits are fixed, like the pool timeouts; the DataStore schema has
no field for them. Tests set them with Store::with_query_timeouts
(test_mode only).

Readiness. /healthz/ready answered 200 whenever a data store was
configured. It now reads one key from the data store with a 2 s limit
and reuses the answer for 2 s, so probes can't load the database;
while one probe runs, others get the last answer. The first failed
probe of an outage is logged. /healthz/live stays 200: restarting a
node doesn't bring its database back, and an orchestrator restarting on
failed liveness would restart every node at once. The container
HEALTHCHECK already uses /healthz/live.

Tests, store::pool_timeout (a proxy that stops forwarding while
keeping connections open plays the paused database):
- postgres_query_timeout, mysql_query_timeout (new): with four pooled
  connections open, a read, a scan and a write each fail with "Query
  timed out" 2.0 s after the pause (2 s test limit); once the proxy
  forwards again the store answers. With the limits set to an hour
  (upstream's behavior), the read was still waiting at the test's 20 s
  limit.
- postgres_readiness (new, STORE=PostgreSql): a node's data store
  goes through the proxy; /healthz/ready is 200, 503 about 4 s after
  the pause while /healthz/live stays 200, and 200 again about 2 s
  after it ends.
- postgres_pool_timeout, mysql_pool_timeout: pass as before.
store::store_tests (PostgreSql, MySql, including the MariaDB statement
timeout step) and store::task_locks (PostgreSql) pass;
store::search_tests (PostgreSql) fails at the same ordering assertion
(query.rs:684) as on main.

crates/store/src/backend/mysql/mod.rs

@@ -6,6 +6,7 @@
  * Modified by Coffey Labs in 2026 for INBUXA.
  */
 
+use crate::backend::query_timeout::QueryTimeouts;
 use crate::{
     search::{
         CalendarSearchField, ContactSearchField, EmailSearchField, FileSearchField, SearchField,
@@ -14,7 +15,7 @@ use crate::{
     write::SearchIndex,
 };
 use mysql_async::Pool;
-use std::fmt::Display;
+use std::{fmt::Display, time::Duration};
 
 pub mod blob;
 pub mod lookup;
@@ -25,6 +26,8 @@ pub mod write;
 
 pub struct MysqlStore {
     pub(crate) conn_pool: Pool,
+    /// inbuxa: client-side query limits (see backend::query_timeout)
+    pub(crate) timeouts: QueryTimeouts,
 }
 
 /// inbuxa: how long a request waits for a pooled connection (including
@@ -54,6 +57,43 @@ pub(crate) async fn pool_conn(
     }
 }
 
+/// inbuxa: the error for an operation that ran past its time limit.
+pub(crate) fn query_timeout_error(limit: Duration) -> trc::Error {
+    trc::StoreEvent::MysqlError
+        .reason("Query timed out")
+        .details(format!(
+            "No answer from the database within {} s",
+            limit.as_secs()
+        ))
+}
+
+/// inbuxa: ends an operation run on `conn` under `limit`. When it ran out,
+/// the connection is closed rather than returned to the pool: a query may
+/// still be in flight on it, or a transaction open. Conn::disconnect marks
+/// the connection closed before it sends anything, so even when the server
+/// doesn't answer and the attempt is dropped, the pool discards it instead
+/// of waiting to clean it up.
+pub(crate) fn bounded<T>(
+    conn: mysql_async::Conn,
+    result: Result<trc::Result<T>, tokio::time::error::Elapsed>,
+    limit: Duration,
+) -> trc::Result<T> {
+    match result {
+        Ok(result) => result,
+        Err(_) => {
+            discard(conn);
+            Err(query_timeout_error(limit))
+        }
+    }
+}
+
+/// inbuxa: closes a connection whose state is unknown (see bounded).
+pub(crate) fn discard(conn: mysql_async::Conn) {
+    tokio::spawn(async move {
+        let _ = tokio::time::timeout(Duration::from_secs(1), conn.disconnect()).await;
+    });
+}
+
 #[inline(always)]
 pub(crate) fn into_error(err: impl Display) -> trc::Error {
     trc::StoreEvent::MysqlError.reason(err)