feat(db): configurable connection pool tuning for MySQL / PostgreSQL

[pushiwuhua7]

Why

Without pool_pre_ping=True, asyncpg leaves connections that were
interrupted by task cancellation (CancelledError) in a half-broken
state inside the SQLAlchemy pool. The next checkout of such a
connection hangs indefinitely, which under concurrent load presents
as the whole app stalling — even though no obvious error surfaces.

The default AsyncAdaptedQueuePool (pool_size=5, max_overflow=10,
pool_timeout=30s) is also too small for production deployments and
provides no recycle behavior to survive managed-PG idle timeouts.

What

Expose the standard SQLAlchemy pool knobs via env vars, applied to
non-SQLite engines only:

Env var	Default	Purpose
DB_POOL_SIZE	10	Persistent pool size
DB_MAX_OVERFLOW	20	Burst capacity
DB_POOL_PRE_PING	true	Detect broken connections on checkout (asyncpg critical)
DB_POOL_TIMEOUT	10	Fail-fast under load (SQLA default 30s "hangs")

SQLite path is unchanged.

Test

• Unit: settings load with defaults, env-var override verified
• Manual: previously-reproducible asyncpg hang under concurrent SSE
  agent execution no longer occurs after enabling pool_pre_ping

[shirshanka]

Thanks for the contribution! Made a few small tweaks - before approving.

[shirshanka]

Approving. Core change is correct and well-scoped — pydantic coerces the int/bool pool env vars properly, the SQLite path is preserved unchanged, and AsyncAdaptedQueuePool (default for async MySQL/PostgreSQL) accepts all five kwargs.

Two follow-up commits were pushed to this branch (maintainer edits):

• Unit tests for the pool settings + _get_engine wiring (SQLite omits pool kwargs; MySQL/Postgres apply them).
• DB_COMMAND_TIMEOUT (asyncpg-only, default 30s, 0 disables) applied via connect_args, so pool_pre_ping's SELECT 1 on a connection wedged by task cancellation fails fast instead of hanging forever — making the hang fix robust rather than probabilistic.

ruff check/format + mypy clean; 17 unit tests pass.