docs: l'écho verbatim passe sur marque fraîche — et deux corrections mesurées

VERDICT SUR L'ÉCHO, sur une marque FRAÎCHE et sans rien déplacer avant : écho
verbatim inchangé -> EnergyErrorNoError, configuration identique, marque
survivante ; écho verbatim + un renommage ailleurs -> EnergyErrorNoError. Nos
deux relevés contradictoires s'expliquent : le premier essai suivait le
déplacement qui avait fait tomber la marque, l'app écrivait donc un "auto" que le
persisté ne portait plus — cas de l'écho périmé, refus correct.
sansRankOriginAuto() peut partir ; relire avant de réécrire le remplace.

CORRECTION LOURDE — le brief promettait à l'app l'inverse de la vérité.
« Supprimer l'entrée d'une borne dont le Thing existe encore la fait recréer au
cycle suivant » est FAUX : mesuré sur .75, entrée retirée, Thing vivant, rien
recréé en 140 s. syncAdapters() n'appelle provisionEvChargerConfig() que dans la
branche !m_adapters.contains(id), et l'adaptateur est construit depuis le Thing —
il survit à la suppression de l'entrée.

Ce que ça produit est le trou de 3g-2 rouvert par le côté client : la borne reste
ARBITRÉE mais ABSENTE de GetLoadConfig, à un rang de queue non réglable
(evPriority() → 1000). Il ne se referme qu'au redémarrage de nymead. Un correctif
est proposé — reprovisionner toute borne sans entrée, pas seulement à la
naissance de l'adaptateur — et NON écrit : c'est un changement de comportement,
la décision appartient à Patrick.

LM-1209-d — le rang est un ordre TOTAL, les domaines ne le partitionnent pas.
L'insertion en queue entrelace les domaines ; la contiguïté n'a jamais été un
invariant et rien dans le moteur n'en a besoin. L'exiger serait CONTRADICTOIRE
avec la raison même de LM-1209 : insérer une charge heating en respectant la
contiguïté décalerait toutes les ev suivantes, soit une détection qui réordonne
une installation qu'un humain a classée. Le même raisonnement vaut côté client :
grouper à l'affichage oui, à l'écriture non — et la note d'entrelacement ne
devrait pas être un avertissement, une liste entrelacée n'ayant rien
d'incohérent.

UN REFUS ARRIVE EN status: "success" — le verdict est dans params.energyError.
Porté en tête d'INTERFACE.md avec l'extrait qui va bien : une sonde qui teste
status annonce « accepté » sur une écriture rejetée, et une sonde qui se trompe
de champ produit un relevé qui a l'air d'un résultat. Même famille que le journal
lu par un sudo qui échoue en silence.

Banc rendu intact : 5 charges, rangs 1-5, marque "auto" en place au rang 5.

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

specs/spec_loadmodel.md

@@ -1369,6 +1369,38 @@ doit pas devenir un geste d'arbitrage.** Renuméroter pour « faire de la place
 l'ordre de service de charges auxquelles personne n'a touché — et le ferait sans qu'aucune
 décision d'exploitation ait été prise.
 
+**LM-1209-d — Le rang est un ordre TOTAL ; les domaines ne le partitionnent pas.** *(Point
+ouvert soulevé par l'agent app, tranché le 2026-08-29.)*
+
+L'insertion en queue entrelace les domaines — `ecs, ev, ev, heating, ev`. Faut-il que
+l'insertion respecte la **contiguïté** d'un domaine, ou que le regroupement automatique côté
+client cesse d'être automatique ? **La seconde.**
+
+**La contiguïté n'a jamais été un invariant, et rien dans le moteur n'en a besoin** : le
+waterfall trie sur le **rang seul**, et `domain` est une métadonnée d'intention que l'arbitre ne
+lit pas (LM-1101 · §3). La contiguïté est une convention d'**affichage**, inventée par le client.
+
+**Et l'exiger du moteur serait CONTRADICTOIRE avec la raison même de LM-1209**, pas seulement
+avec sa condition « aucun autre rang ne bouge ». Insérer une charge `heating` en respectant la
+contiguïté obligerait à décaler toutes les charges `ev` situées après — c'est-à-dire **une
+détection qui réordonne une installation qu'un humain a classée**, exactement ce que LM-1209
+interdit. On ne peut pas invoquer LM-1209 pour la queue et l'enfreindre pour le regroupement.
+
+> **Le même raisonnement s'applique au CLIENT, et c'est le vrai point.** Un regroupement par
+> domaine appliqué **à l'enregistrement** est aussi une machine qui réordonne ce qu'un humain a
+> décidé — au pire moment, et sans que personne l'ait demandé. Il défait l'entrelacement
+> délibéré (« l'ECS après la borne 1 mais avant la borne 2 » est un arbitrage légitime, et le
+> §10 en produira d'autres), et il remonterait au rang 3 une borne que le moteur vient de ranger
+> en queue.
+>
+> **Grouper à l'AFFICHAGE : oui. Grouper à l'ÉCRITURE : non.** Si le regroupement a de la
+> valeur, il doit être un **geste explicite** de l'installateur — visible, réversible —, jamais
+> une normalisation au moment de sauver.
+>
+> **Conséquence sur la note d'entrelacement** : elle ne doit pas s'énoncer comme un
+> avertissement. Une liste entrelacée n'a rien d'incohérent ; l'annoncer comme un défaut pousse
+> à « réparer » un ordre que personne n'a cassé. Au plus une **proposition**.
+
 **LM-1209-c — Une entrée créée d'office DOIT se dire.** Une charge qui prend une place dans
 l'ordre de service sans que rien ne le signale est un **changement d'arbitrage silencieux**. Le
 journal l'annonce déjà ; cela ne suffit pas — l'app ne lit pas le journal, et c'est elle qui