Optimiseur : corrections de relecture du lot 2 — verrou périmé reconnu, application interrompue défaite

Le verrou de l'optimiseur ne doit jamais bloquer quand aucune optimisation
ne tourne, et ne jamais passer pour périmé quand elle tourne. Plusieurs
identités de processus ne tenaient pas ces deux promesses hors Windows.

- Linux : l'instant de démarrage est relatif au boot. Après une coupure, un
  service relancé au même moment du démarrage retrouvait PID et top : le
  verrou de l'ancien passait pour vivant et tout était refusé jusqu'à son
  retrait à la main. L'identifiant du boot le préfixe ; un verrou qui porte
  notre PID sans être l'un des nôtres est périmé.
- Linux : un binaire remplacé par une mise à jour (« (deleted) ») faisait
  passer le propriétaire vivant pour mort. La mise à jour est de toute façon
  refusée pendant une optimisation (interface et loki update).
- macOS : ps rend lstart dans la langue et le fuseau de l'appelant ; le web
  (launchd) et un terminal en français ne lisaient pas la même identité. LC_ALL=C
  et TZ=UTC.
- Un verrou illisible tout juste créé (vide entre création et écriture) n'est
  plus retiré : seulement après 10 s.
- loki tune : terminal fermé ou kill (SIGTERM, SIGHUP) annulent proprement,
  comme Ctrl-C ; Ctrl-C retrouve son sens aux questions de fin.
- Application : la sauvegarde est notée dans le verrou ; un Loki tué avant la
  vérification remet l'ancienne version au redémarrage. Deux clics rapprochés
  ne lancent plus deux applications. Un échec de relance du vrai moteur se
  voit dans le résultat, plus seulement au journal ; un essai qui survit à son
  arrêt reste noté dans le verrou.

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

internal/loki/sys_procid_linux.go

@@ -12,6 +12,11 @@ import (
 // 22 de /proc/<pid>/stat) et binaire d'un processus vivant. Un PID recyclé
 // après un redémarrage de Loki a un autre instant de démarrage : l'optimiseur ne
 // tue un essai orphelin que si les deux concordent (backend_tune_lock.go).
+//
+// L'instant est relatif au boot : après une coupure de courant, un service
+// lancé au même moment du démarrage peut retrouver le même PID ET le même top,
+// et un verrou laissé par l'ancien passerait pour vivant — tout serait refusé
+// jusqu'à son retrait à la main. L'identifiant du boot le préfixe donc.
 func procIdentity(pid int) (start, exe string, ok bool) {
 	if pid <= 0 {
 		return "", "", false
@@ -34,5 +39,14 @@ func procIdentity(pid int) (start, exe string, ok bool) {
 		return "", "", false
 	}
 	exe, _ = os.Readlink("/proc/" + strconv.Itoa(pid) + "/exe")
-	return f[19], exe, true
+	// Binaire remplacé par une mise à jour pendant que le processus tourne : le
+	// lien porte « (deleted) », c'est pourtant bien le même processus.
+	exe = strings.TrimSuffix(exe, " (deleted)")
+	start = f[19]
+	if b, err := os.ReadFile("/proc/sys/kernel/random/boot_id"); err == nil {
+		if id := strings.TrimSpace(string(b)); id != "" {
+			start = id + "/" + start
+		}
+	}
+	return start, exe, true
 }