fix(tests): exiger que le cleanup EFFACE le marqueur, pas qu'il le mentionne

[stephrobert]

Summary

Remplace #55, dont la branche était partie d'un main antérieur au merge de
#46 et ne se rebasait pas proprement. Même contenu, rejoué sur le main
actuel.

Le test devait garantir qu'un lab reste rejouable : ce qu'un creates: protège,
le cleanup.yaml doit le rendre. Sa vérification était assert marqueur in texte — le chemin apparaît quelque part dans le fichier. Un commentaire qui
le cite, ou la lecture . /root/xxx.env, satisfaisaient la condition sans rien
supprimer.

Le défaut, reproduit avant d'être corrigé

La mutation exacte que décrit l'issue, sur l2-filesystem-create-xfs :

-          rm -f /root/xfs-disk.env /root/.xfs-lab-ready
+          echo "cités mais jamais effacés : /root/xfs-disk.env /root/.xfs-lab-ready"

	Résultat
avant le correctif	45 passed, 1 skipped — le test ne voit rien
après le correctif	2 failed, 43 passed, 1 skipped

C'est le piège que la partie « comptes » du même module avait déjà corrigé
avec _est_supprime(), dont la docstring note : « ce test a commencé sa vie
ainsi, et il passait sur un cleanup dont on venait de retirer le userdel ».
La leçon n'avait pas été reportée sur les marqueurs.

Cinq labs remontés, cinq corrigés, aucun exempté

La vérification stricte a fait remonter cinq labs — l'issue le prévoyait — et
tous pour la même raison : le cleanup lit le .env pour connaître le disque,
puis ne l'efface jamais.

Lab	Ce qui manquait
l2-autofs-ondemand	autofs-disk.env absent du rm
l2-disk-space-troubleshoot	dsk-disk.env absent de la loop state: absent
l2-partition-gpt	aucune suppression du tout
l2-storage-performance	perf-disk.env absent du rm -rf
l3-fs-readonly-recover	fsro-disk.env absent du rm -f — le lab de #48

La suppression est placée après la lecture dans chaque cas : l'effacer avant
priverait le cleanup de la variable dont il a besoin. Trois formes distinctes,
traitées une par une plutôt que par une substitution générale qui aurait placé le
rm au mauvais endroit dans au moins l'une d'elles.

Ce que _est_efface() accepte

Deux formes, et seulement elles :

• shell : rm suivi du chemin, éventuellement parmi d'autres ;
• Ansible : une tâche portant à la fois le chemin et state: absent.

Vérification, rejouée sur le main actuel

• la mutation de l'issue rend le test rouge ;
• les cinq cleanup.yaml restent du YAML valide et passent
  ansible-playbook --syntax-check ;
• 880 tests verts (le catalogue en comptait 871 avant le merge de fix(labs): ce que la solution crée, le cleanup doit le rendre #46) ;
• le travail de fix(labs): ce que la solution crée, le cleanup doit le rendre #46 est préservé : aucun de ses cleanups n'est remonté par la
  vérification stricte.

Critères de l'issue

• La mutation ci-dessus rend le test rouge.
• l3-fs-readonly-recover est signalé par le test, puis corrigé (l3-fs-readonly-recover : reset impossible en séquence (hôte injoignable), et son cleanup laisse un marqueur #48).
• Tout autre lab remonté est corrigé — les quatre autres le sont, aucune exemption ajoutée.
• Les formes légitimes restent acceptées : rm -f à plusieurs chemins, et ansible.builtin.file avec state: absent.

Related issues

Closes #49
Refs #48 — le marqueur de l3-fs-readonly-recover est corrigé ici. Le point 1 de
cette issue (l'hôte qui devient injoignable en séquence) reste ouvert : il demande
une campagne de validation réelle.

🤖 Generated with Claude Code