fix(chat): не держать соединение с БД всю жизнь WS-подключения

Обработчик `WS /conferences/{id}/chat` получает `AsyncSession` через
`Depends(get_session)`, а хендшейк делает четыре SELECT'а (тоггл чата,
конференция, тоггл рук, история). SQLAlchemy открывает транзакцию на
первом из них и держит её — вместе с соединением из пула — всё время,
пока участник сидит в комнате. Соединений в пуле `db_pool_size +
db_max_overflow` = 20 на воркер, то есть 40 на инстанс из двух воркеров:
сороковой вошедший выгребал пул досуха.

Ровно это положило вход на нагрузочном тесте 07.08.2026: 245 ошибок
`QueuePool limit ... timed out`, 170 ответов 500 (из них 123 на резолве
конференции и 21 на гостевом входе), а `pg_stat_activity` показывал рост
`idle in transaction` 3 → 8 → 16 → 26 → 35 → 39 → 40 при одном `active`.
Число открытых WS чата в логах backend растёт синхронно и упирается в
те же 40 ровно к моменту первого таймаута пула.

Соединение освобождается сразу после хендшейка: дальше оба насоса
работают через Redis, а единственная запись в БД (`persist_and_publish`)
открывает и коммитит собственную транзакцию.

Замер на локальном стенде (один воркер, потолок пула 20), 15 посторонних
запросов на каждой ступени:

| участников | idle in transaction | 5xx | p95      |
|------------|---------------------|-----|----------|
| было  20   | 20                  | 10  | 10.05 с  |
| стало 20   | 0                   | 0   | 0.02 с   |
| стало 120  | 0                   | 0   | 0.03 с   |

До правки 21-й участник не мог войти вовсе (500 на guest-join), в логе
40 ошибок `QueuePool limit`; после — ни одной на 120 участниках.

backend/api/chat.py

@@ -87,6 +87,26 @@ async def chat_websocket(
     await pubsub.subscribe(channel, room_channel)
     try:
         history = await service.history(conference)
+        # 🔑 Вернуть соединение с БД в пул ДО входа в долгоживущие насосы.
+        #
+        # Хендшейк выше сделал несколько SELECT'ов (тоггл чата, конференция,
+        # тоггл рук, история) — SQLAlchemy открыла транзакцию на первом же из
+        # них и держала бы её, а с ней и соединение из пула, ВСЁ время жизни
+        # WS: участник сидит в комнате час — час занято соединение. Пул это
+        # `db_pool_size + db_max_overflow` на воркер (10 + 10), то есть
+        # 40 на инстанс из двух воркеров, и сороковой вошедший выгребал его
+        # досуха: `pg_stat_activity` показывал 40 соединений
+        # `idle in transaction` при одном `active`, а посторонние ручки
+        # (резолв, гостевой вход, логин, refresh) начинали падать в
+        # `QueuePool limit ... timed out` и отдавать 500. Ровно это положило
+        # вход на нагрузочном тесте 07.08.2026 при ~50 участниках.
+        #
+        # Соединение здесь больше не нужно: оба насоса ниже работают через
+        # Redis, а единственная запись в БД (`persist_and_publish`) сама
+        # открывает транзакцию и коммитит её, освобождая соединение сразу.
+        # ⚠️ Любое чтение из БД, добавленное между этой строкой и концом
+        # обработчика, обязано так же завершаться commit/rollback.
+        await session.commit()
         await websocket.send_json(ChatHistoryOut(messages=history).model_dump(mode="json"))
         seen_ids = {item.id for item in history}