Stockage : Loki signale un /data ou /models servi par le FUSE d'Unraid

Sur Unraid, /mnt/user/… n'est pas un disque mais shfs, un démon FUSE :
chaque fsync de loki.db et chaque page d'un gros MoE mmappé relue depuis
le disque (modèle plus gros que la RAM) le traverse, à chaque token. Rien
n'est perdu ni altéré, mais le décodage ralentit — sans que rien ne le
dise.

Loki ne déplace rien : changer le chemin hôte d'une installation donnerait
un /data vide. Il le voit et le dit, sur un ton d'information :
- sys_storagefuse.go lit /proc/self/mountinfo (type lu après le séparateur
  « - », montage le plus long qui contient le chemin) pour LOKI_HOME et
  chaque dossier de modèles ; Linux en conteneur seulement, mis en cache
  une minute puisque /api/status est interrogé en boucle ;
- conseil en jaune au démarrage et champ « hint » de /api/status, affiché
  en encart discret, distinct du bandeau rouge de perte de données ;
- compose Unraid et README : « Exclusive access » recommandé (même chemin,
  FUSE court-circuité), /mnt/<pool> en option avancée avec migration
  manuelle et mise en garde sur un pool inexistant (RAM).

La détection de thrash du cache de pages est laissée de côté : elle exige
un signal majflt calibré par modèle sur le serveur.

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

internal/loki/web_server.go

@@ -52,6 +52,11 @@ func cmdWeb(args []string) error {
 	if dv := dataVolumeWarning(); dv != "" {
 		fmt.Println(red(dv))
 	}
+	// Simple conseil de performance (fuse.shfs d'Unraid) : jaune, pas rouge —
+	// rien n'est perdu, seul le décodage d'un gros modèle hors RAM ralentit.
+	if sh := storageFuseHint(); sh != "" {
+		fmt.Println(yellow(sh))
+	}
 	if readWebKey() == "" {
 		fmt.Printf("%s API de pilotage NON protégée (aucune clé). Avant de l'exposer sur internet :\n", yellow("[!]"))
 		fmt.Printf("       %s\n", bold("loki set-web-key"))