[P0] Définir les critères de 0.2.0 et vérifier les trois catalogues avant de la poser

[stephrobert]

Contexte

La 0.1.84 réunit ce que l'issue chapeau #66 appelait « productisation » :
contrat v1 gelé et documenté, schémas publiés, API machine versionnée,
authoring (new), gestionnaire de catalogues, machine d'état, verrouillage,
reprise après interruption, diagnostics avancés, suite E2E sur la roue,
documentation par public.

Continuer à empiler des correctifs jusqu'à 0.1.120 aurait moins de valeur que de
stabiliser ce qui existe. Mais poser 0.2.0 demande de savoir ce qu'on promet,
et ce numéro engage : c'est le premier que des intégrations extérieures pourront
citer.

Ce qui manque avant de la poser

• Les incohérences de documentation de 0.1.84 sont corrigées — [P0] docs/catalog-author.md décrit encore le piège des fixtures que 0.1.84 a supprimé #195
  (fixtures) et [P0] CONTRIBUTING.md décrit cli.py et exige des commentaires en anglais : deux règles que le dépôt contredit #196 (cli.py, langue des commentaires).
• Les trois catalogues officiels sont vérifiés avec la version courante :
  list-labs, validate-structure, doctor et un check réel sur au
  moins un lab de chacun. Aujourd'hui seul le comptage est mesuré.
• La compatibilité 0.1.x → 0.2.0 est éprouvée sur l'état existant :
  .dsoxlab.db, .dsoxlab-context.json, le state Terraform et les
  catalogues installés doivent survivre à la montée. Personne ne l'a testé,
  et c'est le genre de chose qui ne se découvre que chez l'utilisateur.
• Les codes de sortie sont centralisés et documentés — [P1] Centraliser les codes de sortie dans un enum typé et publier leur référence #197. Ils
  deviennent une promesse à la 0.2.0 : mieux vaut qu'ils soient à un seul
  endroit avant.
• validate-structure voit tout le disque — [P1] validate-structure ne voit pas les lab.yaml qu'il devrait justement signaler #198, ou la limite est
  documentée explicitement comme tenue pour la v1.

Ce qui n'est PAS un prérequis

À dire pour éviter que la liste ne s'allonge : le découpage de doctor.py
(#199), les ADR (#203) et la déduplication des catalogues (#201) sont de la
maintenabilité. Ils ne changent rien à ce que 0.2.0 promet, et peuvent suivre.

Ce que 0.2.0 promet, à écrire

• Le contrat meta.yml / lab.yaml v1 est stable : quelles évolutions
  restent additives, et qu'est-ce qui déclencherait une v2.
• Le document JSON schema: 1 est stable, et évolue indépendamment du
  contrat des catalogues.
• Les codes de sortie listés ne changent plus de sens.
• Les alias kvm / incus de runtime.type restent acceptés — ou leur
  dépréciation est annoncée avec son échéance.

---

Relevé en confrontant au code une analyse externe du dépôt, le 2026-08-24.
Sous-issues : #195, #196, #197, #198.