Journal moteur : un crash-loop s'affiche « erreur », plus « chargement »

Un llama-server qui plantait au démarrage (backtrace __libc_start_main
dans le journal) laissait la pastille sur « chargement 0 % » pour
l'éternité : aucun des motifs de modelLoadError ne reconnaissait un
crash. Ajoutés : backtrace (signal, segfault, abort), mémoire GPU
insuffisante (out of memory / cudaMalloc failed — avec le conseil de
réduire CTX), et erreur CUDA (GPU indisponible après un redémarrage du
serveur). Pas de motif « libggml » : les logs de chargement normaux
citent les .so.

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

internal/loki/web_api.go

@@ -115,6 +115,27 @@ func modelLoadError() string {
 			if reason == "" {
 				reason = "échec du chargement du modèle"
 			}
+		case strings.Contains(low, "out of memory"),
+			strings.Contains(low, "cudamalloc failed"),
+			strings.Contains(low, "failed to allocate"):
+			// Prioritaire sur l'échec générique : la cause mémoire doit gagner.
+			reason = "mémoire GPU insuffisante (VRAM) — réduis le contexte (CTX) ou prends une quantification plus petite"
+		case strings.Contains(low, "ggml_cuda error"), strings.Contains(low, "cuda error"):
+			if reason == "" {
+				reason = "erreur CUDA — GPU indisponible ? (après un redémarrage du serveur : docker restart loki)"
+			}
+		// Backtrace = le moteur a PLANTÉ, pas « il charge encore ». Les motifs
+		// couvrent le dump de llama.cpp (signal + pile libc) : sans eux, un
+		// crash-loop s'affichait « chargement… » pour l'éternité. PAS de motif
+		// « libggml » : les logs de chargement normaux citent les .so
+		// (« loaded CUDA backend from /app/libggml-cuda.so »).
+		case strings.Contains(low, "__libc_start_main"),
+			strings.Contains(l, "SIGSEGV"), strings.Contains(l, "SIGABRT"),
+			strings.Contains(low, "segmentation fault"),
+			strings.Contains(low, "aborted (core dumped)"):
+			if reason == "" {
+				reason = "le moteur a planté au démarrage (backtrace dans le journal)"
+			}
 		}
 	}
 	if loaded || reason == "" {