Le tri du dossier se déclare, et se contrôle

Le correctif précédent traitait le symptôme : modele_message triait par
« libelle » au lieu de « nom ». Le piège, lui, restait armé — un défaut
« nom » et deux exceptions écartées à la main, alors qu'il se trouvait
seulement que quatre tables sur sept décrivaient des gens ou des
organisations, qui ont des noms. Un défaut vrai quatre fois sur sept n'en est
pas un.

Le piège se referme des deux côtés, parce qu'il en avait deux.

Déclarer
  Record<TablePreparation, readonly string[]>, comme COLONNE_SUPPRESSION le
  fait déjà deux lignes plus haut. Ajouter une table à l'union sans lui donner
  son tri ne compile plus. Le défaut disparaît : il n'y a plus de « sinon,
  nom », il y a sept déclarations.

Vérifier
  Le type oblige à déclarer un tri ; il ne dit pas que la colonne existe.
  C'était l'autre moitié : « nom » était bel et bien déclaré pour
  modele_message, et la table portait un libelle. Un contrôle relit donc
  information_schema et confronte chaque tri déclaré aux colonnes réelles.

  Il tourne juste après les migrations, avant toute lecture du dossier, et ce
  placement est le contrôle lui-même : posé plus tard — il l'a d'abord été —
  la suite tombait avant de l'atteindre, sur « column "nom" does not exist »,
  une erreur qui ne nomme ni la table ni le tri fautif. Après la première
  lecture, il n'aurait plus rien à dire que la chute n'ait déjà dit, et plus
  mal.

Éprouvé en le cassant
  Le défaut d'origine a été réintroduit pour voir le contrôle parler : il
  échoue sur la bonne table et nomme la colonne absente — « le tri de
  modele_message désigne des colonnes qui existent — absente(s) : nom » —
  avant que quoi que ce soit ne tombe. Un contrôle qu'on n'a pas vu échouer
  ne prouve rien.

  898 garanties vérifiées une fois la valeur rétablie, aucune en échec.

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