perf(backend): явный пул соединений БД и несколько воркеров uvicorn

Пул создавался с дефолтом SQLAlchemy (5 + 10) и под нагрузкой выгребался
за секунды. Теперь параметры заданы явно и вынесены в настройки:
DB_POOL_SIZE=10, DB_MAX_OVERFLOW=10, DB_POOL_TIMEOUT=10. Таймаут снижен с
дефолтных 30 секунд намеренно — пусть запрос падает быстро и показывает
проблему, а не висит полминуты.

Backend запускался одним процессом uvicorn: любой блокирующий вызов
останавливал и параллельные запросы, и WS-чат всех участников. Добавлен
UVICORN_WORKERS с дефолтом 2 — не по числу ядер, потому что на
четырёхъядерном сервере ядра делятся с LiveKit, а медиа важнее API.

Бюджет соединений считается на весь инстанс: каждый воркер держит свой
пул, поэтому UVICORN_WORKERS × (DB_POOL_SIZE + DB_MAX_OVERFLOW) должно
оставаться заметно ниже max_connections у Postgres.

Многопроцессность безопасна: бутстрап настроек в lifespan идемпотентен
(INSERT ... ON CONFLICT DO NOTHING), а WS-чат разносит сообщения через
Redis pub/sub и состояния в памяти процесса не держит.

deploy/docker-compose.yml

@@ -82,7 +82,12 @@ services:
       MEDIA_ROOT: ${MEDIA_ROOT:-/app/media}
       # Версия инстанса (релиз v0.0.1) — install.sh копирует значение
       # из файла VERSION (корень репозитория) в .env; отдаётся в GET /api/health.
-      VIDCONF_VERSION: ${VIDCONF_VERSION:-0.0.11}
+      VIDCONF_VERSION: ${VIDCONF_VERSION:-0.0.12}
+      # Число процессов uvicorn (см. backend/Dockerfile). Дефолт 2 рассчитан
+      # на 4-ядерный сервер, где ядра делятся с LiveKit. Поднимая значение,
+      # проверьте бюджет соединений с БД: каждый воркер держит свой пул
+      # (DB_POOL_SIZE + DB_MAX_OVERFLOW), а у Postgres есть max_connections.
+      UVICORN_WORKERS: ${UVICORN_WORKERS:-2}
     # config/ лежит в корне репозитория и не попадает в образ (контекст сборки —
     # только backend/), поэтому plugins.yaml монтируется отдельно.
     volumes: