ops(banc): .75 passe en Europe/Paris, et la couture est datée

`Europe/London` sur un banc français était une erreur de configuration. La
correction a été différée tant que le décalage n'était pas visible : déplacer les
frontières d'une heure sans rien qui le dise aurait rendu l'historique illisible
de part et d'autre, sans qu'aucun lecteur ne puisse savoir où passait la couture.
`periodStartedAt`, posé hier, a levé cette réserve.

COUTURE : 2026-09-05T06:53:30Z. Avant, journée de reporting de 23:00 à 23:00 UTC ;
après, de 22:00 à 22:00. Toute comparaison jour à jour qui franchit cet instant
compare deux découpages différents.

Méthode : `Configuration.SetTimeZone` en JSON-RPC. `System.SetTimeZone` N'EXISTE
PAS en 1.15.2 — malgré la note de dépréciation de `Configuration.SetTimeZone` qui
dit d'utiliser celui-là. Suivre la note aurait donné « No such method ».

CONFIRMÉ EN VRAI : le moteur a suivi SANS redémarrage de nymead. Ce n'était
jusqu'ici mesuré qu'en conteneur avec un programme Qt6 ; `GetEnergyRatios.timeZone`
et `System.GetTime.timeZone` sont passés à Europe/Paris au cycle suivant, et
`periodStartedAt` a reculé de 23:00 à 22:00 UTC.

ET LA PAIRE A SERVI AU MOMENT EXACT OÙ ELLE SERVAIT. `measuredSince` n'a pas bougé
(05:04:29 UTC) : la frontière publiée a changé, la portée réelle de la mesure non.
Sans le second champ, le bilan du jour aurait paru couvrir une heure de plus qu'il
ne couvre — un décalage introduit par la correction elle-même, le lendemain du
jour où on a posé de quoi le voir.

docs/DESIGN_FUSEAU.md

@@ -145,8 +145,33 @@ c'est au client de rapprocher cela de l'heure de son utilisateur, et de l'averti
    moment de la SAISIE d'une échéance, et avertir. C'est l'écran de saisie qui doit parler,
    pas l'écran de résultat — au moment du résultat, l'heure est déjà passée.
 
-### Ce qui reste ouvert, et qu'on ne tranche pas ici
+### Le fuseau de `.75` — corrigé le 2026-09-05, et la date compte
 
-Le fuseau de `.75` lui-même. `Europe/London` sur un banc français est une erreur de
-configuration, mais la corriger déplace d'une heure la lecture de tout l'historique
-d'énergie déjà enregistré. C'est une décision d'exploitation, pas de conception.
+`Europe/London` sur un banc français était une erreur de configuration. La correction a été
+**différée** tant que le décalage n'était pas visible : la déplacer d'une heure sans rien qui le
+dise aurait rendu l'historique illisible de part et d'autre, sans qu'aucun lecteur ne puisse
+savoir où passait la couture. `periodStartedAt` a levé cette réserve — le décalage se lit
+désormais dans la charge utile.
+
+**LA COUTURE, à retenir pour toute lecture de l'historique énergie de `.75` :**
+
+| | |
+|---|---|
+| **Instant du changement** | `2026-09-05T06:53:30Z` — soit 07:53:30 heure box AVANT, 08:53:30 APRÈS |
+| **Avant** | `Europe/London` — journée de reporting de 23:00 UTC à 23:00 UTC |
+| **Après** | `Europe/Paris` — journée de reporting de 22:00 UTC à 22:00 UTC |
+| **Méthode** | `Configuration.SetTimeZone` en JSON-RPC (`System.SetTimeZone` n'existe pas en 1.15.2, malgré ce que dit sa propre note de dépréciation) |
+
+**Tout enregistrement antérieur à cet instant a ses frontières de journée une heure plus tard
+que les suivants.** Une comparaison jour à jour qui franchit la couture compare deux découpages
+différents.
+
+**Ce que la correction a confirmé, en vrai.** Le moteur a suivi **sans redémarrage de `nymead`** —
+ce qui n'était jusque-là mesuré qu'en conteneur (§3). `GetEnergyRatios.timeZone` et
+`System.GetTime.timeZone` sont passés à `Europe/Paris` au cycle suivant, et `periodStartedAt` a
+reculé de 23:00 à 22:00 UTC.
+
+**Et la paire a joué son rôle au moment exact où elle servait.** `measuredSince` n'a PAS bougé
+(05:04:29 UTC, le redémarrage du déploiement de la veille) : la frontière publiée a changé, la
+portée réelle de la mesure non. Sans le second champ, le bilan du jour aurait paru couvrir une
+heure de plus qu'il ne couvre — un décalage introduit par la correction elle-même.