Optimiseur : loki tune et bouton « Optimiser », essais sans perte sur un moteur privé

Chercher à la main le bon micro-lot, les threads ou la marge --fit d'un preset
demandait de dupliquer, basculer et comparer des bench complets un par un.
L'optimiseur le fait sur un moteur d'essai, sans jamais toucher à config.env ni
à ce que calcule le modèle, et n'écrit rien sans un clic.

- Isolation : moteur principal arrêté puis relancé ; chaque essai est une copie
  de la configuration (LOKI_HOME/tune/run), lancée par « loki serve » sur
  127.0.0.1 et un port libre, groupe de processus tué en sortie
- Verrou exclusif inter-processus (LOKI_HOME/tune.lock, PID + démarrage +
  binaire) vérifié par serviceAction start/restart et par le chat, les tâches,
  bash_bg, /v1, le bench, la bascule et l'enregistrement de preset, GPU, clé
  d'API, moteur ; essai orphelin arrêté avant tout démarrage du moteur
- Essais : lots, threads, délestage, marges --fit, files CUDA ; placement --fit
  et SPEC/CUDA_GRAPH_OPT/--backend-sampling seulement sur demande
- EXTRA_ARGS jeton par jeton, liste blanche seulement ; ligne de commande de
  chaque essai composée à blanc et comparée à la référence (« dénature »),
  contexte, slots et cache KV recontrôlés une fois chargé
- Mesure : bench complet du lot 1 à profondeur fixe ; score = durée d'un tour
  type (médianes de la télémétrie) ; gain > max(3 %, écart entre passages)
- Application sur clic : copie du preset, ou preset actuel sauvegardé, réécrit
  clé par clé, vérifié par une sonde et rétabli en cas d'échec

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

internal/loki/sys_service.go

@@ -17,6 +17,23 @@ import (
 //
 // editConfig and showVram live here because they work the same everywhere.
 
+// serviceAction : le seul passage vers serviceActionOS pour le reste de Loki.
+// Pendant une optimisation (backend_tune_lock.go), le moteur d'essai tient la
+// VRAM : démarrer le vrai moteur à côté — bascule de preset, GPU, mise à jour,
+// rechargement… — chargerait deux modèles. Refus, quel que soit l'appelant et la
+// plateforme ; l'optimiseur, lui, appelle serviceActionOS directement. Un verrou
+// périmé (optimisation tuée) est écarté AVANT tout démarrage, son essai
+// orphelin arrêté : sinon le moteur relancé partagerait la carte avec lui.
+func serviceAction(action string) error {
+	if action == "start" || action == "restart" {
+		if err := tuneGuard(); err != nil {
+			return err
+		}
+		tuneReapStale()
+	}
+	return serviceActionOS(action)
+}
+
 // preflightEngine vérifie ce sans quoi le moteur ne PEUT pas démarrer, avant de
 // lancer le service. Sinon llama-server sortait en erreur, systemd le relançait
 // toutes les 3 s, et `loki start` affichait un « activating » rassurant pendant