Moteur : un refus de LOAD_GUARD n'est plus relancé en boucle par systemd

Le refus d'un chargement résident trop gros pour la RAM faisait sortir
« loki serve » en erreur (code 1) ; l'unité loki-engine (Restart=on-failure,
RestartSec=3) le relançait toutes les trois secondes, sans fin, pour un échec
qui ne dépend que du preset et de la machine.

- Le refus sort avec un code dédié, 78 (EX_CONFIG) ; mustExit respecte le
  code porté par l'erreur, toutes les autres gardent 1.
- L'unité écrite par « loki install » porte RestartPreventExitStatus=78 ;
  les autres échecs restent relancés.
- Unité d'une version précédente (« loki update » ne réécrit pas les unités,
  il tourne sans droits root) : reconnue à coup sûr (parent systemd,
  INVOCATION_ID, unité et compléments lus sans la directive), le refus y sort
  sans erreur pour ne pas boucler, avec la marche à suivre au journal.
  Même chose sous launchd, qui relance toute sortie non nulle.
- Le moteur d'essai de l'optimiseur garde toujours le vrai code. Le
  conteneur ne relance jamais le moteur de lui-même : rien à y changer, la
  raison reste au journal et l'interface la montre (modelLoadError).
- Tests : directive reconnue (et seulement elle), code de sortie du refus,
  enveloppé ou non, unité générée (Linux).

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

internal/loki/sys_install_linux_test.go

@@ -0,0 +1,19 @@
+//go:build linux
+
+package loki
+
+import (
+	"strings"
+	"testing"
+)
+
+// L'unité du moteur écrite par « loki install » ne relance pas un refus de
+// LOAD_GUARD : sinon systemd le relançait toutes les trois secondes, sans fin.
+func TestEngineUnitPreventsRefusalRestart(t *testing.T) {
+	if !unitPreventsRefusalRestart(engineUnitTemplate) {
+		t.Fatal("RestartPreventExitStatus absent de l'unité du moteur")
+	}
+	if !strings.Contains(engineUnitTemplate, "Restart=on-failure") {
+		t.Fatal("les autres échecs doivent toujours être relancés")
+	}
+}