Sonde de presence video : la camera muette devient un evenement capteur

Le domaine connaissait deja CAMERA_OFFLINE, classe CRITICAL, mais rien ne
l'emettait. CameraLivenessProbe interroge l'API du serveur media et comble
ce trou.

Elle passe par le meme port IngestSensorEventUseCase que l'endpoint REST
et le simulateur : trois producteurs de natures tres differentes, un seul
contrat d'entree, et le meme trajet Kafka -> agregat ensuite. Si l'alarme
est desarmee, une coupure video ne reveille personne - c'est l'agregat qui
tranche, pas la sonde.

Le seuil est la partie qui compte. Sur un lien 4G le flux tombe
regulierement sans que personne n'ait touche au telephone : tunnel,
bascule d'antenne, congestion. Alerter des la premiere sonde ratee
produirait plusieurs CRITICAL par jour, et on apprend vite a ignorer des
alertes qui crient pour rien - y compris le jour ou elles ont raison.
Trois sondes consecutives, soit une minute d'absence reelle. Six tests
couvrent ce comportement, dont la remise a zero du compteur au retour du
flux.

Utilisateur d'API dedie cote MediaMTX, restreint au reseau Docker interne.

41 tests au vert.

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

deploy/deploy.sh

@@ -29,8 +29,10 @@ echo "==> Rendu de la configuration MediaMTX"
 # part dans le depot. Le fichier rendu est gitignore.
 ssh "${HOST}" "cd ${REMOTE_DIR} && \
     PASS=\$(grep '^STREAM_PUBLISH_PASSWORD=' .env | cut -d= -f2-) && \
+    APIPASS=\$(grep '^MEDIA_API_PASSWORD=' .env | cut -d= -f2-) && \
     PUBLIC_IP=\$(curl -s --max-time 10 https://api.ipify.org) && \
     sed -e \"s|__PUBLISH_PASSWORD__|\${PASS}|\" \
+        -e \"s|__API_PASSWORD__|\${APIPASS}|\" \
         -e \"s|__PUBLIC_IP__|\${PUBLIC_IP}|\" \
         deploy/mediamtx/mediamtx.yml.template > deploy/mediamtx/mediamtx.yml && \
     chmod 600 deploy/mediamtx/mediamtx.yml"

deploy/mediamtx/mediamtx.yml.template

@@ -43,6 +43,15 @@ authInternalUsers:
       - action: read
       - action: playback
 
+  # Lecture seule de l'API, pour la sonde de presence de l'application.
+  # Restreinte au reseau Docker interne : l'API n'est de toute facon pas
+  # publiee sur l'hote, mais deux verrous valent mieux qu'un.
+  - user: probe
+    pass: __API_PASSWORD__
+    ips: ['172.16.0.0/12']
+    permissions:
+      - action: api
+
   - user: iphone
     pass: __PUBLISH_PASSWORD__
     ips: []