Optimiseur : un « loki tune » tué par kill -9 ne laisse plus le moteur arrêté

Le verrou périmé n'était repris qu'au démarrage du processus web. Un
« loki tune » en ligne de commande tué sans ses defers (kill -9, terminal
perdu) laissait donc le vrai moteur arrêté — et peut-être l'essai en VRAM —
jusqu'au prochain redémarrage de l'interface.

- Le processus web refait la reprise toutes les 30 s, avec la même logique
  qu'au démarrage : essai orphelin arrêté (identité complète vérifiée),
  application interrompue défaite, moteur relancé seulement s'il tournait
  avant, ni sur un preset externe ni s'il est déjà reparti.
- Coût : un stat par tic tant qu'aucun verrou n'existe ; pendant une
  optimisation vivante, la lecture du verrou et de l'identité de son
  propriétaire. Une seule goroutine, endormie sur le tic.
- Test : relance au tic qui suit la mort du propriétaire, une fois ; rien
  sans verrou, rien pendant une optimisation vivante, rien pour un moteur qui
  ne tournait pas.

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

internal/loki/web_server.go

@@ -139,9 +139,10 @@ func newWebMux() *http.ServeMux {
 	// Jeton de tentative du décodage spéculatif automatique : effacé dès que le
 	// moteur répond, sans dépendre d'une page ouverte (voir backend_serve_spec.go).
 	startSpecAttemptWatch()
-	// Optimisation interrompue (Loki tué en plein essai) : essai orphelin arrêté,
-	// moteur relancé s'il tournait avant (backend_tune_lock.go).
-	go tuneRecoverAtBoot()
+	// Optimisation interrompue (Loki ou « loki tune » tué en plein essai) : essai
+	// orphelin arrêté, moteur relancé s'il tournait avant (backend_tune_lock.go)
+	// — au démarrage, puis toutes les 30 s (un stat sans verrou).
+	go tuneRecoverWatch(time.NewTicker(tuneRecoverEvery).C)
 	mux := http.NewServeMux()
 	// Pages publiques : le HTML et le JS ne contiennent aucun secret. Toute la
 	// donnée et toutes les actions passent par /api/* qui, lui, exige la clé.