docs: le premier auto-provisionnement réel — trois cas observés, deux trouvailles

Seconde wallbox simulée appairée sur .75 après +etm27. L'entrée n'apparaît pas
instantanément : ma première lecture montrait 4 charges, la suivante 5. Puis tout se
confirme — rankOrigin "auto", rang 5 (insertion en queue), badge sur elle seule, alerte
d'ex æquo muette.

Le coût du §10 est constaté, et il est exactement celui annoncé :

  écho de "auto" par un client        → EnergyErrorInvalidParameter, config INCHANGÉE
  "auto" → "" (ce que fait l'app)     → accepté, LA MARQUE EST EFFACÉE
  "user" sur la seule borne visée     → accepté, rang inchangé, seul ce champ change
  deux renommages voisins ensuite     → "user" SURVIT

Donc le badge a bien disparu d'une borne que personne n'avait classée, au renommage d'une
autre charge — et la fragilité ne touche que "auto".

⚠️ TROUVAILLE 1 — un refus arrive en `status: "success"`, le verdict étant dans
params.energyError. Le service de l'app teste bien les deux ; une sonde jetable écrite le
jour même, non — elle a annoncé « ACCEPTÉ » sur une écriture que la box venait de rejeter,
et c'est le journal de la box qui a rétabli les faits. La raison lisible n'existe que là :
« la charge "Simulated wallbox 2" prétend un rankOrigin "auto" que le moteur n'a pas posé ».
Côté RPC il ne reste que le code. §10 mis à jour avec la table et ce piège.

⚠️ TROUVAILLE 2 — l'insertion en queue CASSE la contiguïté des domaines : ecs, ev, ev,
heating, ev. La note d'ordre entrelacé s'allume donc à juste titre, et prévient que le
premier enregistrement regrouperait — remontant au rang 3 une borne que le moteur avait
rangée en queue. Ce n'est pas un défaut de LM-1209, c'est son prix dès que la dernière
charge n'est pas du même domaine. Trois lectures possibles, portées au brief moteur ; l'app
ne change rien tant que ce n'est pas tranché.

Et une erreur de ma part, dans une sonde jetable et pas dans l'app : j'ai comparé un id de
borne SANS accolades à un id de charge qui en porte — le piège du §9, que j'avais écrit
moi-même la veille. Les chemins de l'app normalisent (chargingModeOf) ou comparent l'id à
lui-même (adoptRank) ; le script, lui, ne trouvait jamais sa cible.

État du banc laissé : libellés restaurés, borne 2 en rankOrigin "user" au rang 5. Le "auto"
est consommé — il faudra un nouvel appairage pour revoir le badge.

226 tests inchangés.

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

docs/BRIEF_plugin_depuis_maquettes.md

@@ -2,6 +2,37 @@
 
 ---
 
+## 2026-08-29 (suite) — l'insertion en queue casse la contiguïté des domaines
+
+**Constaté au premier auto-provisionnement réel** (`Simulated wallbox 2`, `.75`, `+etm27`).
+
+LM-1209 range la borne détectée en queue (`1 + max`), et c'est le bon choix : elle ne passe
+plus devant l'ECS que l'installateur a classé exprès. Mais l'ordre obtenu est :
+
+```
+rang 1  chauffe-eau          (ecs)
+rang 2  V2C Trydan           (ev)
+rang 3  Simulated wallbox    (ev)
+rang 4  PAC banc             (heating)
+rang 5  Simulated wallbox 2  (ev)   ← le domaine `ev` est coupé par `heating`
+```
+
+Le domaine `ev` est **entrelacé**, et l'app le signale — c'est la note posée le 2026-08-28,
+qui prévient que le premier enregistrement **regroupera** et changera donc l'ordre de
+service. Concrètement : la borne rangée en queue par le moteur remonterait au rang 3 au
+premier geste de l'installateur, sans qu'il l'ait demandé.
+
+Ce n'est pas un défaut de LM-1209 : c'est le prix de l'insertion en queue dès que la
+dernière charge n'est pas du même domaine, ce qui est le cas courant. **Trois lectures
+possibles**, et c'est au moteur de trancher : insérer en queue *du domaine* plutôt qu'en
+queue de liste ; assumer l'entrelacement et considérer que le regroupement de l'app est
+l'erreur ; ou déclarer que l'ordre à plat prime et que l'app ne doit pas regrouper.
+
+L'app ne changera rien tant que ce n'est pas tranché : elle regroupe pour afficher depuis le
+début, et elle prévient avant d'écrire.
+
+---
+
 ## 2026-08-29 — `rankOrigin` : un écho inchangé de `"auto"` passe-t-il ?
 
 **Une question, et le contournement posé en attendant.**

docs/UI_data_contract.md

@@ -446,6 +446,30 @@ toutes les charges à chaque écriture, et le badge s'éteint sur une borne que
 classée, au premier renommage d'une autre charge. **Une information qui s'efface au premier
 geste voisin ne vaut pas d'être publiée.**
 
+### Constaté sur machine le 2026-08-29, et la forme du refus
+
+Une seconde wallbox simulée appairée après `+etm27` a produit les trois cas d'un coup :
+`rankOrigin: "auto"`, rang **5** (insertion en queue), badge sur elle seule.
+
+| Écriture | Réponse de la box | État après |
+|---|---|---|
+| renommage d'une AUTRE charge, `"auto"` renvoyé verbatim | `status: "success"` + `energyError: "EnergyErrorInvalidParameter"` | **inchangé** |
+| même renommage, `"auto"` → `""` (ce que fait l'app) | `EnergyErrorNoError` | **la marque est effacée** |
+| `"user"` sur la seule borne visée | `EnergyErrorNoError` | rang inchangé, seul ce champ change |
+| deux renommages voisins ensuite | `EnergyErrorNoError` | **`"user"` survit** |
+
+Le coût annoncé est donc réel et vérifié : le badge « rang posé par la box » a disparu d'une
+borne que personne n'avait classée, au renommage d'une autre charge. La fragilité ne touche
+que `"auto"` — `"user"`, lui, traverse les gestes voisins.
+
+> ⚠️ **Un refus arrive en `status: "success"`.** Le verdict est dans `params.energyError`,
+> et un contrôle sur `status` seul le prend pour un succès. Le service de l'app teste bien
+> les deux (`setLoadConfig`) — mais une sonde jetable écrite le jour même est tombée dans le
+> piège et a annoncé « ACCEPTÉ » sur une écriture que la box venait de rejeter. La raison
+> lisible, elle, ne sort **que** dans le journal de la box : *« la charge "Simulated wallbox
+> 2" prétend un rankOrigin "auto" que le moteur n'a pas posé »*. Côté RPC, il ne reste que
+> `EnergyErrorInvalidParameter`.
+
 ### Ce que ça impose à l'app, aujourd'hui
 
 Le nettoyage vit à un **point de sortie unique** (`NymeaService.setLoadConfig`), jamais sur