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>

.env.example

@@ -27,3 +27,8 @@ LOG_LEVEL=INFO
 # Genere au deploiement, comme DB_PASSWORD :
 #   printf 'STREAM_PUBLISH_PASSWORD=%s\n' "$(openssl rand -hex 16)" >> .env
 STREAM_PUBLISH_PASSWORD=CHANGEME
+
+# Mot de passe de l'API MediaMTX, utilise par la sonde de presence video.
+# Genere au deploiement :
+#   printf 'MEDIA_API_PASSWORD=%s\n' "$(openssl rand -hex 16)" >> .env
+MEDIA_API_PASSWORD=CHANGEME