poste : lire la fabric de son hebergeur, et les modeles

Patient 0 est tenant de SITE-Chezlepro. Son poste clone la fabric et les modeles
en plus du moteur et de son plan, et pose le symlink underlay.yml.

ops-chezlepro reste non clone : le plan d'un tenant voisin n'a rien a faire ici.

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

inventories/production/group_vars/serveur_ops.yml

@@ -0,0 +1,26 @@
+---
+# CE QUE LE POSTE DE PATIENT 0 DOIT DETENIR POUR ENGENDRER.
+#
+# Patient 0 n'a pas de fabric a lui : il est TENANT de l'underlay de Chezlepro
+# (`SITE-Chezlepro`), au meme titre qu'OPS-Chezlepro. Son poste doit donc lire cette
+# fabric-la pour savoir ou poser les VM d'un descendant — sur quel nœud, quel stockage,
+# quel pont. Sans elle, il sait configurer des machines qui existent, pas en creer.
+#
+# ET LES MODELES, parce qu'un descendant ne se cree pas a partir de rien : `make
+# instancier` part d'un modele d'ecosysteme (`exemples/modeles/` pour le generique,
+# `Set-OPS-Modeles` pour les offres nommees).
+#
+# CE QUI RESTE DEHORS, ET DELIBEREMENT :
+#   - `underlay.vault.yml` : les secrets du monde physique, hors depot (gitignore).
+#     Le poste lit la CARTE de la fabric, jamais ses cles.
+#   - `ops-chezlepro` : le plan d'un tenant VOISIN. Patient 0 n'a aucune raison de le
+#     detenir — il est present sur sa forge par le poussage initial du genome, ce qui
+#     est a revoir. On ne le clone pas ici.
+serveur_ops_depots:
+  - { depot: "set-ops-public", dest: "Set-OPS-public", role: "moteur" }
+  - { depot: "ops-patient0", dest: "OPS-Patient0", role: "instance" }
+  - { depot: "site-chezlepro", dest: "SITE-Chezlepro", role: "hebergeur" }
+  - { depot: "set-ops-modeles", dest: "Set-OPS-Modeles", role: "modeles", branche: "master" }
+
+serveur_ops_instance: "OPS-Patient0"
+serveur_ops_underlay: "SITE-Chezlepro"