fix(livekit): один UDP-порт вместо диапазона на 101 порт

Диапазон 54000-54100/udp заставлял Docker поднимать по отдельному
docker-proxy на каждый порт — весь медиатрафик шёл лишним userland-хопом.
rtc.udp_port переключает LiveKit на мультиплексирование ICE-сессий через
один порт; TURN и остальные связи (redis/nginx/webhook/prometheus) не
задеты. Проверено локально lk load-test — 0% потерь пакетов, ICE во всех
сессиях выбирает новый порт.

docs/deploy/capacity.md

@@ -179,12 +179,15 @@ dev-стека.
      профилей битрейта заводить не требуется; при необходимости ограничить
      верхнюю границу — `videoEncoding`/`simulcastLayers` на фронтенде
      (клиентский SDK, вне скоупа devops-части).
-4. **UDP-диапазон 54000-54100 (101 порт)** не был узким местом ни на одной
-   ступени (максимум 60 участников в тесте) — при планировании прод-узла с
-   ожидаемым бОльшим числом одновременных участников across все комнаты
-   узла держать `port_range_end - port_range_start` заметно больше пикового
-   числа участников на узле (LiveKit резервирует пару портов на участника
-   на медиа-транспорт).
+4. **UDP-диапазон 54000-54100 (101 порт)**, на котором проводился этот тест,
+   не был узким местом ни на одной ступени (максимум 60 участников). Тогда
+   же с ним была цена: под каждый порт диапазона Docker держал отдельный
+   процесс `docker-proxy` — 101 порт-101 процесс на медиапути, весь трафик
+   шёл лишним userland-хопом. С переходом на `rtc.udp_port` (один порт,
+   мультиплексирование по ICE ufrag внутри LiveKit) рекомендация «держать
+   диапазон шире пикового числа участников» больше не актуальна — портов
+   для планирования ёмкости не остаётся вовсе, LiveKit разводит участников
+   поверх одного сокета сам.
 5. **STUN/TURN-находка (см. «Методика») —** рекомендуется отдельной задачей
    зарегистрировать `deploy/coturn/` в `rtc.turn_servers` LiveKit и на
    проде, а не только для теста — иначе клиенты в вырожденном случае