spec(LM-1005-b): le fuseau d'une plage tarifaire, en précondition du lot tarifaire

La distinction des deux natures d'heure murale déménage du lot qui l'a découverte
vers le lot qu'elle contraint. Rangée dans DESIGN_FUSEAU.md, c'était une note ;
rangée à l'entrée du lot tarifaire, c'est une condition d'entrée — au même titre
que l'extension du délestage l'était pour le §10.

LM-1005-b, posée juste sous LM-1005, là où la spec nomme déjà la frontière que
l'arbitre franchit en devenant acheteur : « à quel prix, à quelle heure, sous quel
signal tarifaire ». C'est exactement là que le risque naît, et pas un jour avant —
tant que l'arbitre distribue un surplus, il n'a aucune heure à respecter.

  · `dailyDeadline` (habitude du client)   → fuseau de l'installation
  · heures creuses, Tempo, EPEX (calendrier réglementé) → fuseau où le tarif est DÉFINI

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 mauvais moment, et le tarif ne s'est pas décalé. La
facture est le seul endroit où ça se verrait, un mois trop tard.

Le marché de gros amont travaille en instants absolus, donc il est déjà à l'abri.
Le risque apparaît à la première plage écrite en heures murales.

DESIGN_FUSEAU.md ne garde que l'établissement des faits et renvoie ici pour la
règle opposable — pas de règle en double, un seul domicile.

Note de forme, qui a coûté une passe : l'index des règles lit `l.strip()`, donc une
définition placée dans une citation `>` n'est JAMAIS reconnue — elle sort en
« citée et jamais définie ». L'énoncé vit hors de la citation, le bloc d'appui
dedans.

docs/DESIGN_FUSEAU.md

@@ -89,10 +89,15 @@ première c'est correct **si** la box est bien réglée ; pour la seconde c'est
 ne l'est pas. Une grandeur réglementée ne doit donc pas hériter du fuseau système : elle doit
 porter le sien.
 
-> Le marché de gros amont travaille en instants ABSOLUS (les tests construisent leurs
-> horodatages via `EnergyTestBase::utcDateTime`), donc il est déjà à l'abri. Le risque naît
-> le jour où l'on écrira une plage tarifaire en heures murales — c'est-à-dire au prochain lot
-> tarifaire, pas plus tard.
+Le marché de gros amont travaille en instants ABSOLUS (les tests construisent leurs
+horodatages via `EnergyTestBase::utcDateTime`), donc il est déjà à l'abri. **Le risque naît le
+jour où l'on écrira une plage tarifaire en heures murales — et pas un jour avant.**
+
+> **La règle opposable ne vit donc PAS ici.** Elle est écrite là où le risque naît :
+> `specs/spec_loadmodel.md`, **LM-1005-b**, en précondition de livraison du lot tarifaire —
+> au même titre que le délestage était précondition du §10. Une distinction rangée dans le
+> document qui l'a découverte est une note ; rangée dans le lot qu'elle contraint, c'est une
+> condition d'entrée. Ce document n'en garde que l'établissement des faits.
 
 ## 6. La décision : ni imposer, ni refuser — DÉCLARER
 
@@ -122,8 +127,8 @@ c'est au client de rapprocher cela de l'heure de son utilisateur, et de l'averti
 3. **Dire le changement.** Le fuseau peut bouger sous le moteur sans redémarrage (§3). Une
    échéance résolue à 12:00 hier peut valoir 13:00 aujourd'hui sans qu'aucun champ n'ait
    changé. À traiter comme tout élément runtime : un `Get*` ET un `*Changed`.
-4. **Séparer les deux natures** au moment d'écrire la première plage tarifaire : une plage
-   réglementée porte le fuseau où elle est définie, elle n'hérite pas du système.
+4. **Séparer les deux natures** — porté par **LM-1005-b**, précondition du lot tarifaire, et
+   non par ce lot-ci. Rien à faire ici : la condition est posée à l'entrée de l'autre.
 5. **Côté app** (lot séparé, à elle) : comparer le fuseau de la box à celui de l'appareil au
    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.

specs/spec_loadmodel.md

@@ -576,6 +576,36 @@ Tempo).
 - **Le MILP la franchira vraiment** : c'est précisément le problème qu'il sait résoudre —
   placer une énergie obligatoire dans une fenêtre, au coût minimal, sous contraintes.
 
+**LM-1005-b — Une plage tarifaire ne prend pas son fuseau du système : elle porte celui où le
+tarif est défini.**
+
+> **PRÉCONDITION DE LIVRAISON DU LOT TARIFAIRE — pas une recommandation.** Aucune fenêtre
+> tarifaire ne part sans que ce fuseau soit explicite dans la donnée qui la porte — pas dans un
+> commentaire, pas dans une convention d'appel : dans le champ.
+>
+> Il y a DEUX natures d'heure murale dans ce moteur, et elles ne prennent pas leur fuseau au
+> même endroit :
+>
+> | | 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** |
+>
+> 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
+> mauvais moment, et le tarif, lui, ne s'est pas décalé.** La facture est le seul endroit où
+> ça se verrait, et elle arrive un mois trop tard.
+>
+> Le risque naît ICI et nulle part avant. Tant que l'arbitre distribue un surplus, il n'a pas
+> d'heure à respecter ; c'est en devenant **acheteur** qu'il en acquiert une. Aujourd'hui,
+> toute heure murale hériterait silencieusement du fuseau système : correct pour l'habitude du
+> client **si** la box est bien réglée, faux pour le tarif **dès qu'elle ne l'est pas**.
+>
+> Le cas n'est pas théorique : au 2026-09-04, le banc `.75` tourne en `Europe/London`, et une
+> obligation déclarée à `"12:00"` s'y résout à 13:00 heure française. Établi et mesuré dans
+> `docs/DESIGN_FUSEAU.md` — il n'existe qu'UN fuseau, celui du système, et un `nymead` vivant
+> suit son changement sans redémarrage.
+
 **Conséquence de conception** : la passe 1 n'est **pas** bornée par le surplus. Elle est bornée
 par une **autorisation de soutirage** — un objet distinct, que le rule-based rendra binaire et
 que le MILP rendra continu. La passe 2, elle, reste strictement bornée par le reliquat de