Phase 2 : tripoli-edge, service Rust interne derrière Caddy

- tripoli-edge (hyper/tokio bas niveau, pas de framework type axum) :
  /healthz, /metrics (Prometheus, compteurs à la main), reverse-proxy
  vers tripoli-api avec vrais 502 tant que ce service n'existe pas
  (Phase 3), logs JSON structurés par requête.
- Écoute sur 127.0.0.1 + 172.17.0.1 (passerelle docker0), jamais sur
  l'interface publique - même pattern que le Nginx de VoltVision déjà
  sur ce serveur.
- Déployé en prod : systemd (utilisateur système dédié, sans privilège),
  bloc Caddy ajouté pour tripoli.cloud/www.tripoli.cloud, règle ufw
  ajoutée (Ansible) pour que Caddy puisse joindre le port 9000 - sans
  quoi le chemin INPUT de l'hôte bloque le trafic inter-bridges même
  vers 172.17.0.1.
- Vérifié bout-en-bout via https://tripoli.cloud, sans régression sur
  les 6 autres domaines déjà servis par ce Caddy.

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

ansible/roles/base/tasks/main.yml

@@ -34,6 +34,19 @@
     proto: udp
     comment: "tripoli-cloud : WireGuard admin"
 
+- name: Autoriser Caddy à joindre tripoli-edge (172.17.0.1:9000)
+  # Même contrainte que la règle 8090/tcp de voltvision déjà en place :
+  # une requête du conteneur Caddy (réseau "edge", 172.19.0.0/16) vers
+  # 172.17.0.1 (passerelle docker0) passe par la chaîne INPUT de l'hôte,
+  # pas FORWARD - ufw la bloque par défaut même si tripoli-edge écoute
+  # bien sur cette adresse.
+  community.general.ufw:
+    rule: allow
+    from_ip: "172.16.0.0/12"
+    port: "9000"
+    proto: tcp
+    comment: "tripoli-cloud : Caddy -> tripoli-edge"
+
 - name: SSH restreint au tunnel WireGuard uniquement
   when: ssh_restrict_to_wireguard
   block: