Passe de qualité : contexte explosé par les captures, sonde vision, courses

Le journal moteur de production a livré la vraie cause première des 500 en
cascade : « request (55407 tokens) exceeds the available context size
(32768) ». Le message multimodal qui relaie une capture d'écran au modèle
était PERSISTÉ dans l'historique ; son base64 (des dizaines de milliers de
tokens) repartait à chaque tour, et la conversation dépassait
définitivement la fenêtre — plus aucun tour ne passait, et l'exception
Jinja du rattrapage (corrigée au commit précédent) masquait tout.

- L'image devient ÉPHÉMÈRE : jointe au tour en cours, jamais à l'historique.
  Le modèle la regarde maintenant ; sa description textuelle, elle, reste.
- stripImageParts guérit les conversations déjà empoisonnées au chargement
  et à la bascule : parties image retirées, texte aplati.
- engineSeesImages : l'image n'est envoyée que si llama-server DÉCLARE la
  vision (/props, modalities.vision, cache 10 s). La clé MMPROJ ne suffit
  pas — projecteur d'un autre modèle ou modèle sans vision (gpt-oss), le
  gabarit sérialise le base64 en texte. La description de l'outil suit le
  même état : ne jamais promettre une image qui n'arrivera pas.

Deux défauts trouvés à l'analyse, au passage :
- renderBody reconstruit le DOM à chaque delta du streaming : une image déjà
  affichée était RE-TÉLÉCHARGÉE à chaque token arrivé après elle. Cache de
  blobs par URL, une seule requête par capture.
- les opérations de discussions (création, bascule, renommage, suppression)
  entrelaçaient leurs lectures-écritures d'index sous requêtes simultanées :
  sérialisées par un verrou dédié.

Tests : historique guéri (aplati sans l'image), transmission conditionnée à
la sonde, description alignée ; suite complète, vet, staticcheck verts.

internal/loki/chat_sessions.go

@@ -24,6 +24,7 @@ import (
 	"fmt"
 	"sort"
 	"strings"
+	"sync"
 	"time"
 )
 
@@ -33,6 +34,14 @@ const (
 	ckLegacy = "conversation" // fil unique d'avant le multi-discussions
 )
 
+// convOpMu sérialise les opérations de haut niveau sur les discussions
+// (création, bascule, renommage, suppression). Chacune fait plusieurs
+// lectures-écritures de l'index et de la clé active : deux requêtes HTTP
+// simultanées (deux appareils, double-clic) pouvaient entrelacer ces étapes et
+// perdre une entrée d'index ou basculer sur une discussion supprimée. Le verrou
+// de Conversation protège l'état en mémoire, pas cette séquence-là.
+var convOpMu sync.Mutex
+
 // convMeta décrit une discussion SANS ses messages : c'est ce que liste l'UI.
 type convMeta struct {
 	ID      string `json:"id"`
@@ -136,6 +145,8 @@ func ConvList() ([]convMeta, string) { return convIndex(), convEnsureActive() }
 // la cible chargée en mémoire, et l'epoch incrémenté pour que tous les clients
 // rejouent le nouveau fil.
 func convSwitch(id string) error {
+	convOpMu.Lock()
+	defer convOpMu.Unlock()
 	if id == "" {
 		return fmt.Errorf("identifiant manquant")
 	}
@@ -172,11 +183,15 @@ func convCreate() string {
 
 // convNew met de côté la discussion courante puis en ouvre une neuve.
 func convNew() string {
+	convOpMu.Lock()
+	defer convOpMu.Unlock()
 	conv.persist()
 	return convCreate()
 }
 
 func convRename(id, title string) error {
+	convOpMu.Lock()
+	defer convOpMu.Unlock()
 	title = strings.TrimSpace(title)
 	if id == "" || title == "" {
 		return fmt.Errorf("identifiant ou titre manquant")
@@ -196,6 +211,8 @@ func convRename(id, title string) error {
 // sur la plus récente restante — ou sur une discussion neuve s'il n'en reste
 // aucune : il y a TOUJOURS une discussion active.
 func convDelete(id string) error {
+	convOpMu.Lock()
+	defer convOpMu.Unlock()
 	idx := convIndex()
 	next := make([]convMeta, 0, len(idx))
 	found := false