Fix : stopped stream bug

README.md

@@ -689,6 +689,26 @@ Plusieurs profils peuvent être en automatisme sur la même VM ; c'est la
 [priorité](#priorité-et-interruption) qui les départage. **Par défaut la capture en place
 l'emporte** : un profil qui trouve sa VM occupée passe son tour sans rien écraser.
 
+**Une capture déjà ouverte n'est jamais remplacée par une seconde.** Avant de démarrer, le
+serveur demande son état réel à l'agent (`obs.refresh`) au lieu de lire le dernier statut reçu.
+La nuance est décisive : ce statut retombe à « n'enregistre pas » dès qu'une connexion se coupe,
+et repart vide au redémarrage du serveur. Dans cette fenêtre, une VM occupée passait pour libre
+— et l'automatisme rouvrait une capture par-dessus une autre, bien vivante, **du même
+streamer**. Le symptôme : un passage hors-ligne de quelques minutes, la capture mise en pause,
+puis le retour en direct qui la coupait pour en recommencer une.
+
+Selon ce que l'agent répond :
+
+- **capture du même profil en pause** → elle est **reprise**, pas relancée. Le fichier reste le
+  même ; en ouvrir un second aurait perdu le premier ;
+- **capture du même profil en cours** → rien à faire ;
+- **capture d'un autre profil** → l'arbitrage de [priorité](#priorité-et-interruption) s'applique ;
+- **aucune capture** → l'enregistrement démarre, comme attendu.
+
+Second garde-fou en amont : tant qu'un agent n'a rien rapporté sur sa connexion courante,
+l'automatisme s'abstient. « On ne sait pas encore » n'est pas « la VM est libre », et attendre
+le cycle de veille suivant ne coûte rien.
+
 **Trois tentatives par diffusion.** Les échecs restants une fois les garde-fous passés (OBS
 injoignable, par exemple) sont surtout persistants ; au-delà, l'automatisme abandonne
 jusqu'à la diffusion suivante et le dit dans le journal. Passer son tour faute de VM libre