fix bla

README.md

@@ -181,15 +181,21 @@ Le renversement est là : **l'agent possède le navigateur** au lieu de lui envo
 en espérant. Il parle à Firefox, pas au serveur d'affichage — d'où le fonctionnement
 identique sous Wayland, où xdotool ne voit rien.
 
-Séquence du rappel de plein écran, dans cet ordre volontaire :
+Séquence du rappel de plein écran :
 
 1. `browsingContext.activate` — sans quoi la touche partirait vers un onglet d'arrière-plan ;
 2. `input.performActions` — la touche configurée (`f` par défaut), délivrée à la page comme
    un vrai évènement (`isTrusted: true`), donc traitée par le lecteur du site ;
-3. relecture de `document.fullscreenElement` ;
-4. si la page n'a pas bougé : `requestFullscreen()` sur l'élément `<video>`, avec
-   `userActivation` ;
-5. relecture, et verdict rapporté dans l'historique de la VM.
+3. relecture de `document.fullscreenElement`, et verdict rapporté dans l'historique de la VM.
+
+Une seule voie, volontairement, sans repli. Une version antérieure appelait
+`requestFullscreen()` sur l'élément `<video>` brut quand `document.fullscreenElement` restait
+vide après la touche — mais ce champ ne dit rien du mode « théâtre » de Stripchat, qui garde
+la barre du haut visible et n'a le plus souvent rien à voir avec l'API plein écran native du
+navigateur. Le repli déclenchait alors un vrai plein écran natif — vidéo seule, tout le reste
+disparu — l'exact inverse de ce que la touche du lecteur, elle, obtient. `confirmed` reste
+donc indéterminé (`undefined`, pas `false`) quand l'API native ne signale rien : ce n'est pas
+un échec, juste un mode que ce champ ne peut pas observer.
 
 **Un profil Firefox dédié est obligatoire**, pas cosmétique : le port de pilotage ne
 s'ouvre qu'au démarrage du processus, et deux instances ne peuvent pas partager un profil.
@@ -281,19 +287,6 @@ Limite assumée : seuls les cookies sont copiés, pas le `localStorage` ni l'`In
 quasi-totalité des sites, Stripchat compris, portent la session dans un cookie ; si un site
 s'appuyait uniquement sur un jeton en stockage local, cet import ne suffirait pas.
 
-#### Si le plein écran est refusé
-
-Firefox refuse le plein écran à un document **dont la fenêtre n'a pas le focus**. C'est la
-première cause d'échec sur une VM : il suffit qu'OBS ou un terminal l'ait pris. L'agent
-relit alors trois conditions depuis la page et nomme celle qui manque, plutôt que de
-répercuter un « Fullscreen request denied » qui ne dit rien :
-
-| Message | Cause |
-| --- | --- |
-| `la fenêtre Firefox n'a pas le focus` | une autre fenêtre est active dans la session |
-| `aucun élément vidéo dans la page` | le lecteur n'a pas fini de charger — augmente le délai avant plein écran |
-| `l'API plein écran est désactivée dans ce profil` | `full-screen-api.enabled` forcé à faux |
-
 #### Lancement simple
 
 Conservé comme défaut pour ne pas changer le comportement d'un agent existant à la mise à
@@ -370,6 +363,12 @@ puis ajuste la sortie vidéo (`SetVideoSettings`). Trois comportements à conna
   qu'au lancement. L'agent le détecte et le signale dans son compte rendu.
 - **Un preset n'est jamais appliqué pendant une capture** : cela la corromprait. La
   demande est refusée, ou différée jusqu'à l'arrêt de l'enregistrement.
+- **Un preset en attente est toujours écrit avant le `StartRecord` suivant.** Changer de
+  preset juste avant de lancer une capture (la sienne, ou celle d'un autre streamer sur la
+  même VM) ne dépend pas d'un minuteur en tâche de fond : le démarrage attend explicitement
+  que l'écriture soit passée. Sans cette garantie, une capture pouvait démarrer sur l'ancien
+  réglage et y rester verrouillée jusqu'à son propre arrêt — le symptôme perçu était « la
+  qualité ne se met jamais au maximum, et repart au défaut à chaque nouveau stream ».
 
 Le mode de sortie du profil est forcé sur « Simple » : c'est la section que ces réglages
 pilotent. Un paramètre refusé par la version d'OBS installée n'interrompt pas les autres —