fix(0.5.5): deux défauts trouvés en construisant un catalogue (#325)

Deux défauts dont aucun ne se voyait depuis le dépôt du moteur.

`dnsutils` faisait sortir tout provisionnement Debian 13 et Ubuntu 26 en `status: error` : paquet de transition retiré de ces distributions, sans candidat. cloud-init échoue alors sur tout son module de paquets, et le provisionnement continue en annonçant ses hôtes prêts. Mesuré sur une VM Debian 13.7.

`dsoxlab new lab` annonçait une section et écrivait dans une autre : la recherche de `labs: []` portait sur tout le fichier alors que le nom lu était celui de la première section. La position dont le message parlait est l'ordre pédagogique dont `next` se sert.

Plus `scripts/campagnes/`, un descripteur par catalogue, parce qu'une campagne a produit 59 faux ROUGE sur kubernetes et 16 sur iam alors que les deux causes étaient écrites dans le CLAUDE.md du catalogue concerné.

Cinq tests ajoutés, dont quatre prouvés par mutation ; le cinquième est un garde-fou de non-régression et ne prétend pas prouver le défaut.

Author: stephrobert

CHANGELOG.fr.md

@@ -7,6 +7,58 @@ Toutes les modifications notables du projet sont documentées dans ce fichier.
 Le format s'appuie sur [Keep a Changelog](https://keepachangelog.com/fr/1.1.0/),
 et le projet suit le [versionnage sémantique](https://semver.org/lang/fr/).
 
+## [0.5.5] - 2026-10-19
+
+### Corrigé
+
+- **`dsoxlab new lab` annonçait une section et écrivait dans une autre.**
+  `_inscrire_dans_une_section` lisait le nom de la PREMIÈRE section, puis
+  cherchait `labs: []` dans TOUT le reste du fichier. Sur un catalogue à
+  plusieurs sections dont une vide, le lab partait dans cette section vide
+  pendant que le message nommait la première.
+
+  Ce n'est pas un défaut de rangement, c'est un message qui mentait, et la
+  position dont il parlait EST l'ordre pédagogique : `discovery/scanner.py` en
+  dérive `bloc_order`, et `next` s'en sert. Mesuré le même jour sur
+  bdd-dsoxlab-training : deux labs sont partis dans une autre section que celle
+  annoncée, et ce sont exactement les deux créés tant qu'une section vide
+  subsistait.
+
+  La recherche est désormais bornée à la première section. Le défaut demande
+  DEUX sections dont une vide pour se montrer, et un `meta.yml` d'une seule
+  section ne le montre jamais : c'est ce qui lui a permis de survivre.
+
+  Trois tests de `tests/test_scaffold.py` tiennent l'invariant : la section
+  annoncée est toujours celle qui a reçu le lab. Deux d'entre eux rougissent
+  quand on retire la borne.
+
+- **Tout provisionnement Debian 13 ou Ubuntu 26 sortait avec un cloud-init en
+  `status: error`, et aucun `dig` sur les VM.** Les gabarits cloud-init
+  packagés pour Debian et Ubuntu citaient `dnsutils`, qui n'était qu'un paquet
+  de transition : il a été retiré de Debian 13 et d'Ubuntu 26, où il n'a donc
+  plus de candidat. cloud-init échoue alors sur tout son module de paquets,
+  signale l'erreur, et le provisionnement continue en annonçant ses hôtes
+  prêts.
+
+  Mesuré sur une VM Debian 13.7 fraîchement provisionnée : `apt-cache policy
+  dnsutils` répond `Candidate: (none)`, là où `bind9-dnsutils` répond
+  `1:9.20.29-1~deb13u1`. Les autres paquets de la liste étaient bien installés,
+  donc le dégât est borné à l'absence de `dig` et `nslookup`, plus un message
+  d'erreur à chaque provisionnement. Un message qu'on apprend à ignorer ne
+  protège plus personne, et le prochain paquet retiré se cacherait derrière le
+  même bruit.
+
+  `bind9-dnsutils` existe depuis Debian 11 et Ubuntu 21.04 : il couvre donc
+  aussi les distributions plus anciennes du contrat (`debian12`, `ubuntu22`).
+
+  `tests/test_cloud_init_templates.py` refuse désormais un paquet de transition
+  connu pour avoir disparu dans n'importe quel cloud-init packagé, et exige un
+  outil de résolution DNS dans ceux de Debian et d'Ubuntu. C'est un lint, pas
+  une mesure : rien ici n'interroge un miroir, donc il dit seulement qu'aucun
+  paquet connu pour avoir disparu ne figure dans la liste. Elle s'allonge d'un
+  nom chaque fois qu'un provisionnement en désigne un, ce qui est la façon dont
+  celui-ci a été trouvé.
+
 ## [0.5.4] - 2026-10-19
 
 ### Corrigé

CHANGELOG.md

@@ -7,6 +7,55 @@ All notable changes to this project are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.5.5] - 2026-10-19
+
+### Fixed
+
+- **`dsoxlab new lab` announced one section and wrote into another.**
+  `_inscrire_dans_une_section` read the name of the FIRST section, then looked
+  for `labs: []` across the WHOLE rest of the file. On a catalog with several
+  sections of which one was empty, the lab went into that empty one while the
+  message named the first.
+
+  It is not a filing mistake, it is a message that lied, and the position it
+  spoke of IS the teaching order: `discovery/scanner.py` derives `bloc_order`
+  from it, and `next` uses that. Measured on bdd-dsoxlab-training the same day:
+  two labs went into a section other than the announced one, and they are
+  exactly the two created while an empty section still remained.
+
+  The search is now bounded to the first section. The defect needs TWO sections
+  of which one is empty in order to show, and a single-section `meta.yml` never
+  shows it, which is how it survived.
+
+  Three tests in `tests/test_scaffold.py` hold the invariant: the announced
+  section is always the one that received the lab. Two of them go red when the
+  bound is removed.
+
+- **Every Debian 13 and Ubuntu 26 provision ended with cloud-init in
+  `status: error`, and no `dig` on any VM.** The packaged cloud-init templates
+  for Debian and Ubuntu listed `dnsutils`, which was only a transitional
+  package: it was removed from Debian 13 and Ubuntu 26, so it has no candidate
+  there. cloud-init then fails its whole package module, reports the error, and
+  the provision carries on and announces its hosts as ready.
+
+  Measured on a freshly provisioned Debian 13.7 VM: `apt-cache policy dnsutils`
+  answers `Candidate: (none)`, while `bind9-dnsutils` answers
+  `1:9.20.29-1~deb13u1`. The other packages on the list were installed, so the
+  damage is bounded to `dig` and `nslookup` being absent, plus an error message
+  printed on every provision. A message one learns to ignore protects nobody,
+  and the next removed package would hide behind the same noise.
+
+  `bind9-dnsutils` has existed since Debian 11 and Ubuntu 21.04, so it also
+  covers the older distributions the contract declares (`debian12`,
+  `ubuntu22`).
+
+  `tests/test_cloud_init_templates.py` now refuses a known-removed transitional
+  package in any packaged cloud-init, and requires a DNS resolution tool in the
+  Debian and Ubuntu ones. It is a lint, not a measurement: nothing here queries
+  a mirror, so it only says that no package known to have disappeared is
+  listed. The list gains a name each time a provision names one, which is how
+  this one was found.
+
 ## [0.5.4] - 2026-10-19
 
 ### Fixed

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "dsoxlab"
-version = "0.5.4"
+version = "0.5.5"
 description = "Turn declarative exercises into reproducible, runnable and verifiable lab environments"
 readme = "README.md"
 requires-python = ">=3.11"