Migration automatique de l'agencement systeme (Unix)

Sans ca, le renommage n'atteignait pas les machines Linux installees. Le
dossier de donnees y est epingle par /etc/default/jean, que notre propre
installeur ecrit ; le code traitant un chemin explicite comme un ordre, il
ne migrait jamais. Constate en deployant 0.7.0 sur un vrai serveur : les
chemins sont restes en /etc/jean et il a fallu un script separe.

La regle qui debloque : distinguer NOTRE artefact du CHOIX de l'utilisateur.
Si le chemin epingle vaut exactement l'ancien emplacement par defaut, c'est
notre installeur qui l'a ecrit et on migre. Toute autre valeur est une
decision de l'utilisateur et reste intacte.

Le dossier, /etc/default et l'unite systemd bougent ENSEMBLE : les separer
donnerait le pire cas, des donnees deplacees et un service qui ne redemarre
plus. Les chemins sont reecrits par parcours du dossier plutot que d'apres
une liste devinee — l'experience montre qu'ils se cachent dans EXTRA_ARGS,
les copies .bak et jusque dans des notes de MEMORY. backends/ et les .gguf
sont sautes.

Deux moments de declenchement, tous deux root et deliberes : `install`, et
juste apres une mise a jour reussie. Jamais au demarrage ordinaire — un
service qui reecrit des unites systemd a chaque boot finirait par en casser
une, et sur un parc entier ca veut dire des machines qui ne redemarrent plus.

La variante post-mise-a-jour n'arrete AUCUN service : on s'execute dans
jean-link, l'arreter reviendrait a se tuer au milieu de la migration, dossier
deplace et chemins pas encore reecrits. Sans danger, un rename de dossier
sous Linux tolere les fichiers ouverts et un process garde son repertoire de
travail par son inode.

Sauvegarde prealable bloquante, et retour a l'etat initial si une etape
echoue apres le deplacement. Couvert par 6 tests sur un faux /etc, dont le
respect d'un chemin impose et la garantie qu'aucun service n'est touche par
la variante post-MAJ.

RELEASE_NOTES.md

@@ -10,17 +10,21 @@ De même, `JEAN_HOME` reste lu s'il a été défini à la main, au même titre q
 
 ## Le dossier de données se renomme tout seul
 
-Au premier lancement, `%ProgramData%\jean` devient `%ProgramData%\ajean` (`/etc/jean` → `/etc/ajean` sous Linux et macOS).
+`%ProgramData%\jean` devient `%ProgramData%\ajean`, et `/etc/jean` devient `/etc/ajean` sous Linux et macOS. Vous n'avez aucune commande à lancer : la migration se fait pendant la mise à jour.
 
-Le déplacement est instantané, même avec 200 Go de modèles : rien n'est recopié, le dossier est renommé sur place. Les chemins absolus qui pointaient dedans — dont le `--chat-template-file` des presets — sont mis à jour dans la foulée.
+Le déplacement est instantané, même avec 200 Go de modèles — rien n'est recopié, le dossier est renommé sur place. Tout ce qui pointait dedans suit : les chemins absolus de `config.env`, ceux de vos presets (dont le `--chat-template-file`), le fichier `/etc/default`, et le répertoire de travail de l'unité systemd.
 
-Si le renommage ne peut pas aboutir, par exemple parce qu'AJEAN tourne encore en tâche de fond, **il ne se passe rien du tout** : l'ancien dossier reste en place et continue de servir. Rien n'est jamais copié ni supprimé, et la tentative est reprise au lancement suivant.
+Votre clé d'accès distant est déplacée avec le reste : **aucun ré-appairage**, le tunnel se reconnecte seul.
+
+**Si vous aviez choisi vous-même l'emplacement** — un `JEAN_HOME` sur un autre disque, par exemple — il n'est pas touché. Un chemin défini à la main est une décision, pas un héritage à corriger.
+
+Et si le renommage ne peut pas aboutir, par exemple parce qu'AJEAN tourne encore en tâche de fond sous Windows, **il ne se passe rien du tout** : l'ancien dossier reste en place et continue de servir, la tentative sera reprise plus tard. Rien n'est jamais copié ni supprimé.
 
 ## Les serveurs Linux ne perdent pas la main
 
-Une mise à jour remplace le binaire, pas les unités systemd. AJEAN utilise donc le service réellement installé sur la machine : un serveur qui tourne sous `jean.service` continue sous `jean.service`.
+Les unités systemd **ne sont pas renommées**. Un serveur qui tourne sous `jean.service` continue sous `jean.service` : vos commandes `systemctl`, vos règles `sudoers` et vos scripts de supervision restent valables. Seuls les chemins qu'elles contiennent sont corrigés, et une copie de l'unité d'origine est conservée à côté.
 
-Sans cette précaution, le premier redémarrage après mise à jour aurait échoué — sur une machine distante, cela signifie l'accès coupé sans moyen simple de le rétablir.
+Une sauvegarde de la configuration, des presets et de la mémoire est déposée dans `/root` avant toute modification. En cas d'échec à n'importe quelle étape, la machine est remise dans son état initial et les services relancés.
 
 ## Mise à jour