Persistance : le fsync de la discussion ne retarde plus le premier token

StartTurn persistait AVANT de lancer la génération : un marshal, puis deux
commits bbolt (contenu, puis index), soit deux fsync et plusieurs ouvertures
de base — 26-30 ms mesurés sur un NVMe Windows, bien plus sur un /mnt/user
d'Unraid ou un disque de parité, payés à chaque message avant que la requête
ne parte vers llama-server. Même facture au milieu d'un tour (vérification du
mode Code) et pour chaque résultat d'outil coupé (« voir plus »).

- chat_persist.go : un écrivain unique et ordonné. L'instantané reste pris
  sous c.mu (images → références, marshal, identifiant de la discussion) ;
  seule l'E/S part en différé. Le dernier instantané de chaque discussion
  l'emporte (numéro pris sous c.mu), les lots sont fusionnés en UNE
  transaction : contenu + index ensemble, résultats d'outils compris.
- Seuls StartTurn, la persistance en cours de tour et les résultats d'outils
  sont asynchrones. Fin de tour, reset, bascules, compactage manuel restent
  synchrones et attendent tout ce qui précède ; la suppression écarte puis
  attend les écritures qui la visent (plus de discussion ressuscitée).
- Discussion active gardée en RAM, créée sous verrou (plus de double
  identifiant sur base neuve) et changée sous c.mu avec le contenu : un
  instantané ne peut plus écrire l'ancien fil sous le nouvel identifiant.
- « Voir plus » servi depuis la mémoire tant que le résultat n'est pas écrit ;
  verrouillage vérifié avant de rendre un id.
- En plein tour, la base reçoit le journal sous sa forme de fin de tour
  (compactLog, version pure de compactLogLocked) ; la mémoire n'est pas touchée.
- Vidage de l'écrivain avant redémarrage, « Quitter », exec et (dé)chiffrement.

Le contexte vu par le modèle ne change pas : il lit c.Messages en mémoire, les
résultats complets d'outils et la compaction du journal ne servent qu'à l'UI.

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

internal/loki/tool_results.go

@@ -45,13 +45,23 @@ func toolResID(sid string) string {
 // saveToolResult enregistre un résultat complet de la discussion ACTIVE et
 // renvoie son id ("" en cas d'échec : l'appelant envoie alors le résultat
 // entier dans le flux).
+//
+// L'écriture est confiée à l'écrivain de la discussion (chat_persist.go) : un
+// tour d'agent qui coupe vingt résultats payait vingt fsync entre l'outil et
+// l'étape suivante. Le résultat est servi depuis la mémoire jusqu'à ce qu'il
+// soit sur disque (loadToolResult).
 func saveToolResult(result string) string {
-	id := toolResID(getStr(bkChat, ckActive))
-	// Chiffrement actif mais mémoire verrouillée : putStoreBytes refuse d'écrire
-	// en clair, et l'appelant envoie alors le résultat entier dans le flux.
-	if id == "" || putStoreBytes(bkToolRes, id, []byte(result)) != nil {
+	id := toolResID(convEnsureActive())
+	// Chiffrement actif mais mémoire verrouillée : on refuse d'écrire en clair,
+	// et l'appelant envoie alors le résultat entier dans le flux. Vérifié ICI,
+	// pas à l'écriture : un id rendu doit désigner un résultat qu'on écrira.
+	if id == "" {
 		return ""
 	}
+	if _, err := memEncoderNow(); err != nil {
+		return ""
+	}
+	persistQ.enqueueToolRes(toolResJob{path: dbPath(), key: id, plain: result})
 	if toolResWrites.Add(1)%toolResPruneGap == 0 {
 		go pruneToolResults()
 	}
@@ -63,6 +73,9 @@ func loadToolResult(id string) (string, bool) {
 	if strings.ContainsAny(id, "/\\") {
 		return "", false
 	}
+	if s, ok := persistQ.toolResPending(id); ok {
+		return s, true
+	}
 	b, err := getStoreBytesErr(bkToolRes, id)
 	if err != nil || b == nil {
 		return "", false
@@ -76,6 +89,7 @@ func deleteToolResultsFor(sid string) {
 		return
 	}
 	prefix := sid + "."
+	persistQ.dropToolRes(prefix)
 	_ = update(bkToolRes, func(b *bolt.Bucket) error {
 		c := b.Cursor()
 		var keys [][]byte