Le .env se complète, il ne se réécrit plus par défaut

Devant un .env existant, l'installateur savait le garder ou le réécrire. Rien
entre les deux. Or c'est entre les deux que se trouve à peu près toujours ce
qu'on veut d'une mise à jour : garder ce qui est là, prendre ce qui est
nouveau.

Ce que réécrire coûtait
  Un .env en service porte des choses que ce script n'a pas écrites et ne sait
  pas redemander : la clé .p8 d'Apple, le compte de service Firebase, le mot
  de passe du relais SMTP, et toute valeur qu'un exploitant a ajustée à la
  main. La sauvegarde à côté les préservait, mais il fallait ensuite les
  recopier une à une — c'est-à-dire s'en souvenir.

  « Le compléter » devient la première porte, et le défaut.

Deux gestes, dans cet ordre
  Renommer d'abord. Une clé qui a changé de nom n'est pas une clé absente : la
  compléter poserait la valeur d'exemple à côté de la vraie, et comme la
  composition préfère le nouveau nom, c'est l'exemple qui l'emporterait. Le
  même piège que preparer-env.mjs a déjà rencontré, et pour la même raison.

  Ajouter ensuite ce que .env.example a et que le fichier n'a pas, en tirant
  au sort les secrets qui restent marqués — SESSION_SECRET en 32 octets, les
  autres en 24, le mot de passe de base en 16, et DATABASE_URL reconstruite à
  partir de ce que le fichier dit déjà plutôt que d'une base que personne n'a
  créée.

Ce qui n'est jamais touché
  Une valeur déjà présente. Et une clé que .env.example ne connaît pas : elle
  est signalée, jamais retirée, parce qu'elle vient peut-être d'un réglage
  local dont ce script n'a pas à décider.

Contrôlé
  Sur un .env réel d'avant le passage à l'anglais : 29 clés en entrée, 48 en
  sortie, 14 renommées et 19 ajoutées, aucune perdue, aucune valeur modifiée,
  aucun doublon, le mode 600 conservé. Relancer la migration ne trouve plus
  rien à faire et laisse le fichier à l'octet près. Un SESSION_SECRET retiré
  puis remigré revient en 64 caractères hexadécimaux tirés au sort, et non en
  valeur d'exemple. Les trois autres portes — garder, réécrire, ne rien faire
  — répondent toujours, et la réécriture reprend toujours les identifiants
  Postgres devant un volume existant.

Un défaut trouvé en chemin, dans ce commit même : « $_vieux→$_neuf » perdait
son nom de variable, sh happant le premier octet de la flèche — qui n'est pas
de l'ASCII — dans le nom qui la précède. Les accolades le règlent, et c'est le
genre de faute que seule l'exécution montre.

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