fix(db): bound asyncpg statement and connect time so a dead socket recovers (port of #1552 to main) - #1679

Port of #1552 from speedkick to main.

Cherry-pick of 10b3706d5574080153a62b678196989dbc24f85f, the squash commit #1552 merged as on
speedkick. It applied to main with no conflicts, and the diff is
byte-identical to the one reviewed on #1552 (checked with git patch-id), so the
review there still stands.

Re-checked on this branch, based on main:

• ruff check and ruff format --check clean repo-wide on the pinned ruff 0.16.8.
• Server unit suite: 1869 passed, 3 skipped — identical to main. This PR adds no
  tests; the fault-injection evidence below is from fix(db): bound asyncpg statement and connect time so a dead socket recovers #1552 and was not re-run here.

The body below is #1552's, unchanged.

A pooled connection whose peer stops responding is not an error, it is a wait.
The kernel retransmits with exponential backoff — observed at tcp_retries2
attempt 13, Send-Q stuck at 34 bytes and unchanged over 20 seconds — and
asyncpg has no deadline of its own, so the request blocks for the whole of it.

pool_pre_ping does not help: its liveness SELECT is written into the same
dead socket and waits with everything else.

The failure this produces is worse than a slow request. The pool never
discards the dead connections, so the process stays wedged after the network
recovers and only a restart clears it. Seen twice on a benchmark deployment:
searches timing out indefinitely while /api/v2/health answered in about a
millisecond, four uvicorn workers idle in select(), no lock contention in
Postgres, and a fresh connection from the same pod completing in 18 ms.

create_async_engine was passed no connect_args, so nothing bounded either the
statement or the connect. This adds command_timeout and connect_timeout,
defaulted to 60 s and 10 s and settable to null for the old behaviour. Both are
gated on driver == "asyncpg": they reach asyncpg.connect() and mean nothing to
aiosqlite or aiomysql.

The keyword assembly moves into a helper, because adding a branch to
async_get_sql_engine pushed it past ruff’s complexity limit and the repeated
"if not None" lines were asking for it.

Verified by fault injection

iptables DROP on the pod’s traffic to Postgres:5432, so pooled connections wedge
exactly as they did in the incident:

The recovery is the point. The stock build stays wedged once the network is
healthy again, which is what forced the restarts.

What this does not claim

Under a total outage the request still takes ~194 s to fail rather than ~60 s.
A search touches three separate stores, so it pays a timeout per store: the bound
is roughly command_timeout × stores touched, not command_timeout. Lowering the
default would shorten it proportionally.

60 s is chosen, not tuned. It is generous against real query times here, which
are milliseconds, and is left configurable rather than optimised. Reviewers who
know the workload better should push back on it.

Caveats for review

• Not built and tested from this branch alone — the image used for the fault
  injection carried this change and the startup-warming fix together, on top of
  the Qdrant wiring from fix(metrics): wire the Qdrant vector store, and let a build include it #1532.
• ruff check and ruff format --check pass.