Prévenir que « production » ne démarre pas encore

L'installateur demandait si l'instance était en production, écrivait
KASTELL_ENV=production, et rendait la main. L'application, elle, refuse ce
mode tant qu'aucun transport de courriel n'est configuré : le transport
« console » écrirait les liens de connexion dans « docker logs », et il vaut
mieux ne pas démarrer que le découvrir dans un journal.

Le refus est juste. Ce qu'il réclame n'existe pas.

  definirTransport n'est appelé que par le harnais de vérification. Il n'y a
  pas d'adaptateur SMTP, pas de variable d'environnement pour en désigner un,
  et les passerelles Brevo ou OVH que branche une organisation servent les
  envois de masse, pas les liens d'authentification — auth/comptes.ts passe
  par adaptateurs/notify, qui reste sur « console ».

  Conséquence : aujourd'hui, KASTELL_ENV=production ne démarre pas. En boucle,
  avec une erreur qui nomme sa cause mais pas le fait qu'elle est sans issue.

Ce que le script fait maintenant
  Il le dit à la question, là où la décision se prend, et propose de revenir à
  « developpement » — au prix, énoncé, des liens de connexion visibles dans
  les traces. Rester en production reste possible : quelqu'un qui écrira le
  transport avant de démarrer a le droit de le vouloir.

  Ce script écrit une configuration, il ne promet pas qu'elle démarre. Mais
  quand il sait qu'elle ne démarrera pas, se taire n'est pas de la réserve.

Ce que ce commit ne fait pas
  Écrire le transport manquant. C'est une pièce à part entière — adaptateur,
  variables, documentation, contrôle — et la bâcler dans un correctif
  d'installateur donnerait le pire des deux : une production qui démarre et
  des courriels qui ne partent pas.

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