Pièces jointes : mêmes garde-fous vision que les captures d'écran

Vu en production : un projecteur mmproj d'un AUTRE modèle sélectionné dans le
preset (Qwen3-VL-8B sur un Qwen3.8-27B). Le projecteur ne se charge pas,
mais visionEnabled() — qui ne teste que la clé MMPROJ — répondait vrai : la
pièce jointe partait en image_url que le gabarit sérialisait en texte. Un
PNG de 3,5 Mo devenait des dizaines de milliers de tokens dans le contexte,
et le modèle annonçait quand même « je ne peux pas voir les images ».

userMessageContent exige désormais aussi engineSeesImages() (/props,
modalities.vision) — la même double condition que le relais des captures.
Sans vision effective, la pièce jointe est annoncée comme fichier, comme
avant le multimodal.

internal/loki/web_upload.go

@@ -187,7 +187,12 @@ func visionEnabled() bool {
 // modèle d'aller ouvrir un fichier qu'il a déjà sous les yeux) ; les autres
 // fichiers, eux, restent annoncés comme avant.
 func userMessageContent(files []attachInfo, prompt string) any {
-	if !visionEnabled() {
+	// Double condition : MMPROJ configuré ET moteur qui déclare la vision
+	// (/props). Avec un projecteur d'un AUTRE modèle — donc jamais chargé — le
+	// gabarit sérialisait le base64 de la pièce jointe en TEXTE : un PNG de
+	// 3,5 Mo devenait des dizaines de milliers de tokens dans le contexte, le
+	// même engorgement que celui corrigé pour les captures d'écran.
+	if !visionEnabled() || !engineSeesImages() {
 		return attachNote(files) + prompt
 	}
 	dir, err := uploadsDir()