Docs : compléments de l'audit v1.8.2 (commentaire clé labResults + pistes différées)

- ChartScreen : one-liner sur la clé « labResults entière » (le pourquoi
  du fix #66, là où on lit le code).
- §20.bis : les 4 pistes d'optimisation écartées/différées de l'audit
  (importJson batch, BootReceiver goAsync, fusion generateForecastDoses,
  cache terminalDecayParameters) — avec la raison de chaque report, pour
  qu'une future session ne redécouvre pas et ne re-pose pas les questions.

app/src/main/java/com/hormonetrack/ui/screens/ChartScreen.kt

@@ -276,7 +276,10 @@ fun ChartScreen() {
     val curves by produceState(
         emptyList<Pair<String, List<LevelPoint>>>(),
         autoByModel, doseLogs, startMs, endMs, showEse, showTfs, showWhs, showForecast,
-        showLabTrack, showLabTrackExtend, labResults
+        showLabTrack, showLabTrackExtend,
+        // Clé = la liste ENTIÈRE des labs (pas .size, fix #66) : éditer la
+        // VALEUR d'une analyse doit recalculer les courbes
+        labResults
     ) {
         withContext(Dispatchers.Default) {
             val list = mutableListOf<Pair<String, List<LevelPoint>>>()

docs/DEVELOPPEMENT.md

@@ -1981,6 +1981,32 @@ E2+T en une entrée (v1.2.2), migration Room v1→v2 sans fallback destructif
 (push session).
 8. Phase 2 montre : watchface `.hwt` custom, puis mini-app Lite Wearable (cf §17)
 
+### 20.bis Pistes d'optimisation écartées ou différées (audit v1.8.2)
+
+L'audit complet de v1.8.2 a relevé 4 pistes **délibérément NON appliquées**
+(gain réel mais risque/effort hors critère « comportement identique, sûr ») —
+pour ne pas les redécouvrir et re-reposer les mêmes questions :
+
+1. **`importJson` par lots** : les inserts ligne à ligne = une transaction
+   Room par ligne. `@Insert` en liste préserverait l'ordre (IDs) et
+   accélérerait l'import d'un gros historique. Différé : surface DAO +
+   repository à modifier, validation manuelle (aucun test Room auto).
+2. **`BootReceiver` : consolidation `goAsync` + une seule lecture** :
+   les deux `runBlocking` séquentiels peuvent fusionner trivialement ; le
+   passage complet au pattern `goAsync`+coroutine de ReminderReceiver est
+   équivalent mais re-testé sur émulateur (boot). Différé.
+3. **Double évaluation de `generateForecastDoses`** dans ChartScreen
+   (producer `forecastDoses` vs producer `curves`) : NE PAS fusionner tel
+   quel — le premier utilise `System.currentTimeMillis()`, le second le
+   `nowMs` figé au tick ; unifier change l'ensemble des créneaux
+   « strictement futurs » à la frontière de la minute (observable).
+   À unifier UNIQUEMENT avec une décision explicite sur le nowMs de référence.
+4. **Cache `terminalDecayParameters`** (PKProfileStore) : le scan O(8 001)
+   recalculé à chaque `sample()` extrapolé pourrait être mémoïsé (tables
+   immuables après init) — coût réel modeste (l'extrapolation ne sert que
+   pour dt ≥ 8 001 h) ; introduit de l'état mutuel → à ne faire que si un
+   profilage le justifie.
+
 ## 21. Checklist de test manuel
 
 Sur le téléphone de test (à compléter par l'utilisatrice) :