LiveKit: jeden port UDP dla wszystkich (mux) zamiast zakresu

Zakres port_range 50000-50100 rezerwowal osobny port na kazde polaczenie.
Test z 200 botami wszedl dokladnie w 49, a log serwera pokazal kandydata
UDP tylko przy 52 polaczeniach i TCP przy wszystkich 204: kolejni
uczestnicy dostawali juz tylko TCP. Zmienna UDP_PORT z zakresem nie
wlaczala muxa, bo przegrywala z zakresem z pliku.

Teraz udp_port: 7882 (sprawdzone lokalnie: rtc.portUDP Start 7882, End 0),
nowa zmienna LIVEKIT_UDP_PORT, zeby stara LIVEKIT_UDP_RANGE w .env nie
mogla przywrocic zakresu.

Automatyczne wdrozenie nie dotyka profilu livekit: kontener trzeba
przeladowac recznie.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -2040,10 +2040,19 @@ Wlaczenie: `docker compose --profile livekit up -d`.
 - **Wersja serwera musi nadazac za `livekit-client`.** Klient 2.22 laczy sie
   sciezka `/rtc/v1`, ktorej serwer 1.8 nie zna: sala wyglada na dzialajaca,
   ale nie plynie ani obraz, ani dzwiek. Obraz przypiety do `v1.13`.
-- **Zakres UDP 50000-50100 musi byc otwarty.** To glowna droga audio i wideo.
+- **Port UDP 7882 musi byc otwarty.** To glowna droga audio i wideo.
   Bez niego uczestnicy dolacza do pokoju i zobacza liste obecnych, ale nie beda
   sie slyszec: to najczestsza przyczyna zgloszenia "wideo nie dziala" przy
   poprawnie skonfigurowanym serwerze.
+- **Jeden port UDP dla wszystkich (`udp_port`, tryb mux), NIGDY zakres.**
+  Przy `port_range_start/end` serwer rezerwuje osobny port na kazde polaczenie.
+  Zakres 50000-50100 konczyl sie po okolo 50 uczestnikach: test z 200 botami
+  wszedl dokladnie w 49, a log serwera pokazal kandydata UDP tylko przy 52
+  polaczeniach i TCP przy wszystkich 204. Przegladarka wchodzi wtedy po TCP
+  (zacinajacy sie obraz przy utracie pakietow), klient bez ICE-TCP nie wchodzi.
+  **Zmienna `UDP_PORT` z zakresem nie wlaczala muxa**: przegrywala z zakresem
+  z pliku, a wczesniejsza analiza wziela ja za dzialajacy mux. Rozstrzyga log:
+  `connectionType` i kandydaci `[local]` przy wejsciu uczestnika.
 - **coturn dziala w `network_mode: host`**, bo TURN musi widziec prawdziwe
   adresy IP. Za NAT-em Dockera rozdawalby uczestnikom adresy wewnetrzne
   kontenera, pod ktore nikt z zewnatrz sie nie polaczy.