docs(§10): +etm52 — la contradiction progressMeasurable/regime est levée, mesurée

Sonde sur le banc, version relue avant (1.15.2+etm52, posée le 03/09), obligation
déclarée puis retirée, restauration « 0 écart, clé par clé ».

`progressMeasurable: true` et `regime: "measured"` sortent enfin sur la même
charge : l'avertissement de saisie parlera là où il faut, et l'achat à l'aveugle
a cessé pour une charge instrumentée. `deliveredWh` est présent (0, pas absent),
`measuredSince` stable sur sept cycles.

`purchasedWh` et `deliveredWh` divergent — 27,5 Wh achetés, 0 livré — et c'est ce
qui prouve qu'ils ne font pas doublon. Ici la cause est bénigne :
`ECS-Meter.totalEnergyConsumed` vaut 10 depuis le 1er septembre, constante du
mock. Mais la divergence donne à l'écran un contrôle qu'il n'aurait pas su
fabriquer : sous `measured`, acheté qui monte et livré qui reste plat = soit la
charge ne consomme pas, soit le compteur ne compte pas.

Non conclu : la décroissance de `remainingWh`, donc l'étalement adaptatif. Elle
exige un cumul qui avance. Le comportement observé est aujourd'hui identique à
celui d'`unmeasurable` pour une raison entièrement différente — la coïncidence
même qui ferait conclure juste sur une mauvaise raison.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw

docs/BRIEF_plugin_depuis_maquettes.md

@@ -2,6 +2,46 @@
 
 ---
 
+## 2026-09-04 — `+etm52` : la contradiction est levée, mesurée
+
+Obligation déclarée puis retirée (`chauffe-eau`, 4 000 Wh avant 12:00, sept cycles, restauration
+depuis la capture — *« 0 écart, clé par clé »*). Version relue avant de sonder : `1.15.2+etm52`,
+posée le 03/09 à 06:52:20, `nymead` actif.
+
+```jsonc
+"progress": { "regime": "measured", "targetWh": 4000, "deliveredWh": 0,
+              "measuredSince": "2026-09-04T03:42:00Z", "purchasedWh": 27.52 }
+```
+
+**`progressMeasurable: true` en configuration et `regime: "measured"` en télémétrie, sur la même
+charge.** La contradiction est levée : l'avertissement de saisie parlera là où il faut, et l'achat
+à l'aveugle a cessé pour une charge instrumentée. `deliveredWh` est **présent** (0, pas absent) —
+la distinction est tenue dans le bon sens. `measuredSince` porte l'instant d'ouverture et ne bouge
+plus sur sept cycles.
+
+### `purchasedWh` et `deliveredWh` divergent, et c'est ce qui prouve qu'ils ne font pas doublon
+
+Sous `measured` : **27,5 Wh achetés, 0 Wh livré**. Sur ce banc l'explication est bénigne —
+`ECS-Meter.totalEnergyConsumed` vaut **10 depuis le 1er septembre**, c'est une constante du mock,
+relevée deux fois à une seconde d'intervalle. Le chemin est branché et lu ; la grandeur qu'il lit
+ne bouge pas.
+
+Mais la divergence elle-même est le fait utile : elle donne à l'écran un **contrôle qu'il n'aurait
+pas su fabriquer**. Sous `measured`, `purchasedWh` qui monte pendant que `deliveredWh` reste plat
+veut dire *soit* que la charge ne consomme pas ce qu'on achète, *soit* que le compteur ne compte
+pas. Deux causes, deux gestes, et aucune n'est inventée par l'app.
+
+### Ce qui reste inobservable ici, et je ne le conclus pas
+
+**La décroissance de `remainingWh`**, donc l'étalement adaptatif. Elle exige un cumul qui avance :
+il faudrait un compteur de banc dont `totalEnergyConsumed` progresse, ou une charge réelle. Le
+comportement observé — `remainingWh` figé à 4 000 — est aujourd'hui **identique** à celui de
+`unmeasurable`, pour une raison entièrement différente et bénigne. C'est exactement le genre de
+coïncidence qui ferait conclure juste pour une mauvaise raison, et tenir jusqu'au jour où quelqu'un
+bâtit sur la raison.
+
+---
+
 ## 2026-09-03 (suite) — avant d'écrire `sessionWh` sur un compteur : la garde ne peut pas être le recul
 
 Le correctif est le bon, et l'ordre aussi. Une mise en garde avant qu'il soit écrit, parce