fix(collections): déclarer les collections Ansible employées

[stephrobert]

Résumé

Trois collections Ansible hors ansible.builtin sont employées par ce dépôt, et
aucune n'était déclarée. Deux se trouvaient installées par hasard sur la
machine de développement ; la troisième, non.

Conséquence, sur une infra fraîchement provisionnée :

83 vert(s), 1 rouge(s), 0 ignoré(s) sur 84 lab(s).
  ✘ rhcsa-mock-exam    20 warnings, 20 errors

Le message envoyait chercher au mauvais endroit

RuntimeError: solution.yaml a échoué pour rhcsa-mock-exam (rc=4, status=failed). Stats : {}

rc=4 est le code « unreachable » d'Ansible, et des stats vides se lisent
comme « aucun hôte joint ». Quatre pistes ont été instruites avant la bonne :
l'état des VM, l'inventaire, la clé SSH, le déchiffrement vault. Pendant ce
temps, dsoxlab status rendait les trois hôtes verts et ansible -m ping alma-rhcsa-2.lab répondait pong.

La cause n'apparaît qu'en jouant la solution à la main :

[ERROR]: couldn't resolve module/action 'community.crypto.openssh_keypair'

Après ansible-galaxy collection install community.crypto, le capstone passe
20/20 en 59 s, sans autre changement.

Ce que le dépôt emploie réellement

Recensé sur tous les labs/** et toutes les solution/**, déchiffrées :

Collection	Occurrences
ansible.builtin	604
ansible.posix	3
community.general	1
community.crypto	1

Le garde-fou

tests/test_collections_declarees.py refuse qu'une collection employée manque à
requirements.yml. Il porte sur ce que les fichiers emploient, pas sur ce
que la machine a d'installé : une suite verte parce que le poste est bien garni
ne dit rien de celui du prochain qui clone.

Il déchiffre les solutions au passage, et un second test vérifie que ce
déchiffrement a bien eu lieu — sans quoi le premier passerait au vert sans
avoir rien regardé, la panne du harnais déguisée en succès.

Le hook est câblé dans .pre-commit-config.yaml, faute de quoi
outillage-coherent refuse le commit — et il a raison : « un vérificateur
présent mais débranché ne protège plus rien, en silence ».

Éprouvé par mutation : retirer community.crypto de la déclaration fait
échouer le test en nommant le fichier fautif ; restauré, les deux passent.

Un faux départ, corrigé et documenté

Le premier motif cherchait mot.mot.mot n'importe où dans le texte et remontait
auto.master, logs.tar, net.ipv4, dl.flathub — des chemins, une archive,
un nom de domaine. Un garde-fou qui crie au loup se fait désactiver, alors il ne
regarde plus que la position de clé dans une tâche. La raison est écrite dans le
fichier, pour que personne ne « simplifie » le motif plus tard.

Au passage

runtime.hosts_required disparaît du capstone : le champ n'est lu ni par
dsoxlab ni par ce dépôt, et le compte d'hôtes est déjà porté par
runtime.targets[]. C'est l'un des quatre champs morts que les schémas JSON de
dsoxlab 0.1.54 ont fait apparaître.

Ce que cette PR ne fait PAS

Le message d'échec du replay n'est pas retouché. Une première version de ce
travail l'améliorait, avant de constater que main le traite déjà depuis
« un replay de solution en échec doit dire pourquoi » (#42) : la fin du stdout
du playbook y est collée au message. Le doublon a été abandonné, et cette branche
repart de main à jour plutôt que de le traîner.

Validation

Infra provisionnée (alma-rhcsa-1/2.lab, ubuntu-lfcs-1.lab), solutions
rejouées avec contrôle du verdict :

84 vert(s), 0 rouge(s), 0 ignoré(s) sur 84 lab(s).

Issues

Closes #50

🤖 Generated with Claude Code