Cache : PREWARM prépare le prochain tour pendant que l'utilisateur lit, en opt-in

Une compaction, un dernier message rendu autrement au tour suivant ou une
tâche planifiée qui a pris le slot laissent au message suivant un recalcul
inévitable : des secondes sur un 27B, des dizaines sur un MoE aux experts en
RAM, avant le premier mot. Nouvelle clé PREWARM (off par défaut) : dès que le
moteur local est libre, Loki lui envoie la requête du prochain tour suivie
d'un message utilisateur « . », max_tokens 1, sans flux. Le moteur calcule le
préfixe et pose un point de reprise au début de ce message ; le vrai tour ne
calcule plus que le sien. Sans la clé, aucune requête de plus (testé).

- assemblage partagé, contenu vivant : turnViewDry (même code que turnView,
  sans rien toucher à la discussion, décision PROJ_SNAPSHOT via
  projSnapDecide), wireMessages, turnReasoning et buildChatPayload, extraits
  de runChat ; corps identique à l'octet près à celui d'avant (matrice
  d'options et de modes, testée contre une copie de l'ancien code)
- jamais devant un vrai travail : toute requête de Loki l'annule au départ
  (compteur de llm_slots.go, sous son verrou), sauf un tour de chat dont les
  messages sérialisés, outils et arguments du gabarit prolongent exactement
  le préfixe préchauffé
- moteur local, un seul slot (/props total_slots), pas pendant un tour, une
  tâche, un bench, un travail annexe ni une requête en vol ; un seul à la
  fois ; pas si le prochain tour compactera, ni à moins de 10 min de minuit
- requête brute : ni compaction, ni relance, ni effort appris, ni CtxUsed,
  ni stats ; erreurs lâchées (une ligne de journal par statut) ; rien persisté
- déclencheurs : fin de tour sans file d'attente, fin de tâche (projet forcé
  levé, slot effacé) ; full = aussi changement de discussion après 3 s
- capacités du dernier tour gardées en mémoire par discussion ; mode Code =
  rôle d'un message ordinaire, une demande de plan diverge et annule
- télémétrie kind=prewarm ; la vérification du cache RAM après une tâche se
  fait sur lui

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

README.md

@@ -387,6 +387,24 @@ Ajoutées par ce fork :
   tâches planifiées gardent le bloc à jour à chaque tour ; sans agent, rien du
   projet n'est envoyé ; un preset externe (API) n'est jamais concerné. Le titre, l'export JSON, le résumé de compaction et la
   passe de vérification ne voient pas ces blocs.
+- **Préchauffage du prochain tour** (clé `PREWARM`, **off** par défaut,
+  `loki config set PREWARM on`) : certains recalculs sont inévitables — prompt
+  réécrit par une compaction, dernier message rendu autrement au tour suivant,
+  discussion reprise après une tâche planifiée qui a pris le slot — et sans la
+  clé ils retardent le premier mot du message suivant. Avec `on`, dès que le
+  moteur local est libre après un tour ou une tâche, Loki lui envoie la requête
+  du prochain tour, assemblée par les mêmes fonctions que la vraie (contenu
+  vivant, rien de figé), suivie d'un message `.` et limitée à 1 jeton : le
+  moteur calcule le préfixe pendant que tu lis, et le vrai message ne calcule
+  plus que lui-même. Le jeton et le `.` sont jetés, rien n'est enregistré. Toute
+  autre requête de Loki l'annule aussitôt, sauf un message dont la requête
+  prolonge exactement le préfixe préparé (même historique, mêmes outils, mêmes
+  réglages du gabarit). Jamais avec plus d'un slot (`PARALLEL` ou `-np` dans
+  `EXTRA_ARGS`), pendant un tour, une tâche, un bench, ni vers un preset externe.
+  `full` prépare aussi la discussion qu'on ouvre, si on y reste 3 s. Visible dans
+  la télémétrie sous `prewarm`. Ce que voit le modèle ne change pas : au pire, le
+  préchauffage ne sert à rien (moteur sans points de reprise aux messages
+  utilisateur, image juste avant, agent ou web changé avant d'envoyer).
 - **Discussions multiples** : historique complet dans la barre latérale, titre
   repris du premier message (renommable), suppression. **Chaque discussion a son
   dossier de fichiers** (`workspace/discussions/<id>/`) : les pièces jointes