Kamera i ekran dla konkretnego uczestnika z panelu prowadzenia

Karta "Na sali" dostala przelaczniki kamery i udostepniania ekranu przy
kazdym uczestniku (wylacznie LiveKit). Uprawnienia licza sie z trzech
niezaleznych praw (PublishRights: mikrofon, kamera, ekran) zamiast jednej
roli, w jednym miejscu dla tokenu i zmiany na zywo; serwer pokoju nadaje
i odbiera je bez ponownego wejscia na sale.

Kolumny camera_allowed i screen_allowed (V32), domyslnie false. Zgoda
indywidualna przezywa wylaczenie "wideo dla wszystkich". Uczestnik
dostaje komunikat, a przy ekranie ostrzezenie, ze sala zobaczy wszystko.

PublishRightsTest i PublishRightsTokenTest pilnuja, ze zgoda na jedno
zrodlo nie otwiera innego; oba sprawdzone w obie strony.

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

CLAUDE.md

@@ -75,8 +75,12 @@ Trzy role, egzekwowane uprawnieniami w tokenie dostepu, nie regulaminem:
 | prelegent | publikuje obraz i dzwiek |
 | uczestnik | tylko odbiera, ma czat i pytania |
 | uczestnik z glosem | publikuje wylacznie dzwiek, po zgodzie moderatora |
+| uczestnik z kamera albo ekranem | publikuje obraz lub ekran, wylacznie po indywidualnej zgodzie prowadzacego |
 
-Wideo uczestnikow jest zawsze wylaczone na poziomie uprawnien.
+Wideo i ekran uczestnikow sa **domyslnie** wylaczone na poziomie uprawnien.
+Wlacza je wylacznie prowadzacy: calej sali ("wideo dla wszystkich", bez ekranu)
+albo konkretnej osobie (kamera i ekran osobno, patrz "Indywidualna zgoda na
+kamere i ekran"). Uczestnik sam niczego sobie nie wlaczy.
 
 ## Zasady pracy
 
@@ -1683,6 +1687,33 @@ Tabela `speak_requests` (V17), kolejka w panelu prowadzenia, temat WebSocket
   czekajacy piec minut widzi, jak mowi ktos zgloszony przed chwila.
 - Pilnuje tego `SpeakRequestTest`, w tym dziesiec rownoczesnych zgloszen.
 
+### Indywidualna zgoda na kamere i ekran
+
+Kolumny `registrations.camera_allowed` i `screen_allowed` (V32), przelaczniki
+w karcie "Na sali", endpoint `POST /admin/webinars/{id}/room/participants/{rid}/publish`.
+
+- **Trzy niezalezne prawa, nie jedna rola** (`PublishRights`: mikrofon, kamera,
+  ekran). Kombinacji jest osiem, a enum rol na kazda oznaczalby, ze latwo
+  przeoczyc, ktora odziedziczyla za duzo. `RoomRole` zostaje dla dostawcow
+  znajacych tylko role (`closestRole`, nigdy PRESENTER).
+- **Zgoda na jedno zrodlo nie otwiera innego.** Sam ekran to nie kamera, sama
+  kamera to nie mikrofon. Pilnuja tego `PublishRightsTest` (uprawnienia na zywo)
+  i `PublishRightsTokenTest` (lista zrodel w podpisanym tokenie), oba sprawdzone
+  w obie strony.
+- **Prawa licza sie w jednym miejscu** (`VideoService.participantRights`) dla
+  tokenu i dla zmiany na zywo. Zgoda indywidualna jest niezalezna od trybow sali:
+  wylaczenie "wideo dla wszystkich" nie odbiera kamery osobie, ktorej dano ja osobno.
+- **Tylko przy LiveKit.** Wylacznie tam serwer egzekwuje osobno kazde zrodlo;
+  przy innych dostawcach panel nie pokazuje tych przelacznikow.
+- **Kolejnosc: zapis, serwer pokoju, zdarzenie.** Zdarzenie `PUBLISH_CHANGED`
+  sluzy przegladarce do pokazania komunikatu i pobrania aktualnego biletu na
+  wypadek ponownego wejscia; samo uprawnienie zmienil juz serwer.
+- **Uczestnik z prawem do ekranu dostaje ostrzezenie**, ze sala zobaczy wszystko,
+  co pokaze, lacznie z powiadomieniami. Przycisku udostepniania nie da sie
+  przechwycic (to pasek LiveKit), wiec ostrzezenie wisi, dopoki zgoda trwa.
+- Pasek sterowania LiveKit pokazuje przyciski wedlug `canPublishSources`, wiec
+  uczestnik z samym ekranem widzi tylko przycisk ekranu.
+
 ### Moderacja wyrazow
 
 Tabela `moderation_words` (V31), ekran `/moderacja-wyrazow`, endpointy
@@ -2098,7 +2129,8 @@ ustawienie `VIDEO_PROVIDER`. Na start dwie: `NONE` i `DAILY`.
 - **Uprawnienia wynikaja z tokenu u dostawcy, nie z interfejsu.** Ukrycie przycisku
   kamery niczego nie zalatwia: uczestnik moze podmienic kod strony albo wejsc wlasnym
   klientem. `RoomRole` przeklada sie na `permissions.canSend` w tokenie.
-  **Wideo uczestnika jest wylaczone zawsze**, takze po podniesieniu do SPEAKER.
+  **Wideo uczestnika jest domyslnie wylaczone**, takze po podniesieniu do SPEAKER.
+  Kamere i ekran daje wylacznie prowadzacy (`PublishRights`).
 - `RegistrationRoomRole` (VIEWER, SPEAKER) jest celowo wezszy niz `RoomRole`:
   uczestnik z zapisu **nigdy** nie dostaje uprawnien moderatora. Ma je wylacznie
   prelegent z `webinar_speakers`, wchodzacy wlasnym linkiem. Pilnuje tego