Renommage AJEAN (2/3) : services, binaire et releases

Suite du renommage. Principe directeur : le code s'adapte a ce qui est
DEJA installe sur la machine, plutot que d'exiger une migration
privilegiee qui pourrait echouer et laisser un serveur sans service.

Services (sys_unitname.go). Une mise a jour remplace le binaire, pas les
unites systemd : un serveur deja installe tourne encore sous jean.service
et jean-link.service. serviceName() et linkServiceName() resolvent donc
le nom a l'usage — l'unite qui existe reellement — au lieu de supposer
"ajean*". Sans ca, le premier systemctl restart apres MAJ echouerait, et
sur un serveur distant ca veut dire l'acces coupe sans terminal pour
reparer. Meme logique pour le label launchd, ou le prefixe com.jean. est
conserve tant que c'est lui qui est charge.

Le fichier PID du worker de lien est repris au passage (jean-link.pid ->
ajean-link.pid) : c'est lui qui dit si un worker tourne, et sans reprise
la premiere version renommee en aurait demarre un second, donnant deux
tunnels concurrents vers le relais.

Binaire. installedExePath vise desormais ajean(.exe), et l'installation
pose un alias "jean" a cote — lien symbolique sous Unix, copie sous
Windows ou les liens demandent des droits qu'on n'a pas toujours. La
commande d'hier reste tapable : on ne controle ni les alias shell, ni les
cron, ni les scripts de deploiement, ni les tutos deja ecrits.

/etc/default/ajean est ecrit avec AJEAN_HOME ET JEAN_HOME, et l'ancien
/etc/default/jean est laisse en place plutot que supprime : des scripts
d'utilisateurs le sourcent.

Releases. Les workflows produisent ajean-<os>-<arch> puis en copient un
jeu jean-<os>-<arch> identique, une fois les binaires macOS recuperes.
Les deux jeux sont dans SHA256SUMS. Ces copies sont indispensables : le
parc installe ne sait chercher que jean-*, il ne pourrait donc meme pas
atteindre la version qui apprend a lire ajean-*. A retirer quand le parc
aura bascule. Le bundle devient AJEAN.app, avec le zip publie sous les
deux noms pour ne pas casser les liens de telechargement deja diffuses.
La detection du mode application se basant sur /Contents/MacOS et non sur
le nom du bundle, elle n'est pas affectee.

internal/ajean/sys_paths.go

@@ -26,14 +26,22 @@ type ajeanPaths struct {
 }
 
 // installedExePath est l'emplacement canonique du binaire après installation.
-// Il diffère par plateforme : sous Unix les installateurs posent /usr/local/bin/jean
+// Il diffère par plateforme : sous Unix les installateurs posent /usr/local/bin/ajean
 // (c'est ce que référencent les unités systemd et le plist launchd) ; sous Windows,
-// faute d'équivalent, on utilise JEAN_HOME\bin ajouté au PATH utilisateur.
-func installedExePath() string {
+// faute d'équivalent, on utilise AJEAN_HOME\bin ajouté au PATH utilisateur.
+func installedExePath() string { return exePathNamed("ajean") }
+
+// legacyExePath est l'emplacement d'avant le renommage. L'installation continue
+// d'y poser un alias : `jean` reste tapable indéfiniment. Ça ne coûte qu'un lien
+// et ça préserve les habitudes, les scripts cron, les alias shell et les tutos
+// déjà écrits par les utilisateurs — dont on ne contrôle aucun.
+func legacyExePath() string { return exePathNamed("jean") }
+
+func exePathNamed(name string) string {
 	if runtime.GOOS == "windows" {
-		return filepath.Join(AjeanHome(), "bin", "jean.exe")
+		return filepath.Join(AjeanHome(), "bin", name+".exe")
 	}
-	return "/usr/local/bin/jean"
+	return "/usr/local/bin/" + name
 }
 
 func currentPaths() ajeanPaths {