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 и состояния в памяти процесса не держит.

backend/Dockerfile

@@ -37,4 +37,13 @@ EXPOSE 8000
 HEALTHCHECK --interval=10s --timeout=5s --retries=10 --start-period=15s \
     CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/api/health')" || exit 1
 
-CMD ["uv", "run", "uvicorn", "main:create_app", "--factory", "--host", "0.0.0.0", "--port", "8000"]
+# Число воркеров — из окружения (`UVICORN_WORKERS`, см. docker-compose.yml).
+# Один процесс означает, что любой блокирующий вызов в обработчике
+# останавливает весь event loop: параллельные запросы и WS-чат всех
+# участников встают в очередь. Дефолт 2, а не «по числу ядер»: медиа
+# важнее API, и на 4-ядерном сервере LiveKit в пике забирает 1.6 ядра.
+#
+# `sh -c` нужен ради подстановки переменной (exec-форма её не делает),
+# `exec` — чтобы uvicorn получил PID 1 и корректно принимал SIGTERM.
+CMD ["sh", "-c", \
+     "exec uv run uvicorn main:create_app --factory --host 0.0.0.0 --port 8000 --workers ${UVICORN_WORKERS:-2}"]