docs: quatrième mode d'érosion, et la troisième nature d'heure murale

QUATRIÈME MODE D'ÉROSION — l'inverse du troisième. La règle immortelle survit
parce que sa garde la protège ; celle-ci meurt parce que le CHEMIN qui y menait
s'est raréfié, et c'est un CORRECTIF qui l'a raréfié.

Le taux constant (LM-1013-b-v) a été décidé le 2026-09-01 avec son chiffrage.
Puis sessionWh a été alimenté depuis le compteur de charge et `unmeasurable` est
passé de « la V2C, tous les jours » à trois cas matériels rares. La décision n'a
jamais été écrite, et plus personne ne passait devant pour s'en apercevoir.

Ce qui rend la classe traître : le correctif est un PROGRÈS. On ne se méfie pas
de ce qui améliore les choses. Réduire un régime dégradé à ses cas irréductibles
est exactement ce qu'il faut faire — et c'est ce qui a fait disparaître la
décision de la vue. Parade : quand un lot RÉDUIT la fréquence d'un chemin, lister
ce qui vivait dessus et n'a pas été fait. Une décision non écrite ne se périme pas
au rythme de sa pertinence mais au rythme de sa VISIBILITÉ, et les deux viennent
de se découpler.

UN CHIFFRE FAUX DANS UNE SPEC finit par servir de prémisse. Variante numérique du
raisonnement faux sous une conclusion juste — et elle se transmet plus facilement,
parce qu'un chiffre se cite et se recopie sans ses conditions. Le ×2,5 aurait
voyagé avec « 4 kWh » et sans « fenêtre de 2,5 h ». Règle : un chiffre porte les
conditions qui le produisent, ou il se refait avant d'être écrit ; et quand il
change, la spec garde les deux valeurs et la raison de l'écart.

« LENT PAR CONSTRUCTION » ET « FIGÉ » ONT LA MÊME FORME. Règle d'investigation,
pas un fait sur selfConsumptionRate — lui va bien : sur un cycle de surplus
complet il a parcouru 53,4 → 98,4 en 54 valeurs distinctes. La leçon n'est PAS
« observer plus longtemps » : ça aurait marché ici et ça échoue sur une grandeur
à cadence horaire. Le discriminant est la NATURE de la grandeur — instantanée,
cumulée sur une période, événementielle — et elle se lit dans le contrat, pas dans
le signal. Sans cette phrase, toute observation est trop courte ou trop longue
sans qu'on puisse le savoir.

TROISIÈME NATURE D'HEURE MURALE : la période de REPORTING. GetEnergyRatios dérive
ses Δ depuis minuit local. Elle suit l'installation, ce qui est le bon
comportement — mais elle repose sur la même prémisse non vérifiée que l'échéance
client : que le fuseau de la box SOIT celui de l'installation. Sur .75, le bilan
journalier de l'app se remet à zéro à 01:00 heure française, et rien ne le dit.

Ce que la troisième ajoute : la prémisse « la box est bien réglée » ne porte pas
seulement une saisie, elle porte des GRANDEURS PUBLIÉES. Une échéance mal
fuseau-horée se corrige d'un réglage ; un bilan journalier découpé au mauvais
endroit a déjà été lu, affiché, et peut-être facturé. La colonne « qui le
vérifie » de DESIGN_FUSEAU.md répond « personne » pour celle-là.

docs/DESIGN_FUSEAU.md

@@ -75,10 +75,22 @@ ce qu'on s'interdit ailleurs (`measurement.source`, `rankOrigin`, `progress.regi
 
 Elles ne prennent pas leur fuseau au même endroit, et les confondre est le piège.
 
-| | nature | fuseau qui fait foi |
-|---|---|---|
-| `dailyDeadline`, « avant 7 h » | **habitude du client** | celui de l'installation |
-| heures creuses, Tempo, EPEX | **calendrier réglementé** | celui où le tarif est DÉFINI |
+| | nature | fuseau qui fait foi | qui le vérifie |
+|---|---|---|---|
+| `dailyDeadline`, « avant 7 h » | **habitude du client** | celui de l'installation | l'app, à la saisie |
+| heures creuses, Tempo, EPEX | **calendrier réglementé** | celui où le tarif est DÉFINI | `LM-1005-b`, au lot tarifaire |
+| taux journaliers (« minuit local ») | **période de reporting** | celui de l'installation | **personne** |
+
+La troisième s'est trouvée en cherchant autre chose : `GetEnergyRatios` dérive ses Δ **depuis
+minuit local** (`docs/INTERFACE_energyratios.md` §2). Elle suit l'installation, ce qui est le bon
+comportement — mais elle repose sur la même prémisse non vérifiée que la première : que le fuseau
+de la box SOIT celui de l'installation. Sur `.75`, le bilan journalier de l'app se remet à zéro à
+01:00 heure française, et rien nulle part ne le dit.
+
+**Ce que la troisième nature ajoute au raisonnement** : elle montre que la prémisse « la box est
+bien réglée » ne porte pas seulement une saisie, elle porte des **grandeurs publiées**. Une
+échéance mal fuseau-horée se corrige d'un réglage ; un bilan journalier découpé au mauvais
+endroit a déjà été lu, affiché, et peut-être facturé.
 
 Une plage d'heures creuses française est définie en `Europe/Paris` par le fournisseur, pas
 « à l'heure locale de la box ». Une box française mal réglée ne décale pas seulement

specs/spec_loadmodel.md

@@ -590,6 +590,13 @@ tarif est défini.**
 > |---|---|---|
 > | `dailyDeadline`, « avant 7 h » | **habitude du client** | celui de l'installation |
 > | heures creuses, Tempo, EPEX | **calendrier réglementé** | celui où le tarif est **défini** |
+> | taux journaliers (« minuit local ») | **période de reporting** | celui de l'installation |
+>
+> La troisième a été trouvée en cherchant autre chose (2026-09-04) : `GetEnergyRatios` calcule
+> ses Δ **depuis minuit local**. Elle suit l'installation, ce qui est CORRECT — mais seulement si
+> le fuseau de la box est celui de l'installation. Sur `.75`, en `Europe/London`, le bilan
+> journalier de l'app se remet à zéro à **01:00 heure française**. Le comportement du moteur est
+> juste ; c'est la prémisse qui est fausse, et rien ne la vérifie.
 >
 > Une plage d'heures creuses française est définie en `Europe/Paris` par le fournisseur, pas
 > « à l'heure locale de la box ». Les confondre ne décale pas un affichage : **ça achète au