docs(releve): le banc pose AVANT de publier — correction du §8-bis (a)

Ma rédaction se rassurait à tort : « +etm12 n'est pas perdu, .75 était réparable depuis le dépôt
APT à tout moment ». C'est vrai de cette version-là, et faux comme raisonnement.

.75 est le banc de BÊTA-TEST : on y pose un paquet AVANT de le publier. Sur le banc, un paquet
pas encore publié n'existe qu'à deux endroits — le répertoire de dépôt de la box et le pool
local de build. Ni au dépôt APT, ni chez un client, ni dans aucun git (un .deb ne se versionne
pas). L'écraser est IRRÉVERSIBLE, et c'est cela, plus que le ramassage multiple, que le verrou
d'archivage protège.

Le journal dpkg de la box, désormais cité, donne la chronologie qui le montre : +etm12 posé sur
le banc le 13 août à 19:48, publié au pool à 20:48 — une heure où il n'existait QUE sur le banc.
La plupart des paquets de banc ne quittent jamais cette fenêtre, puisqu'ils sont écartés : c'est
leur raison d'être. Le risque ne dépend pas de la chance qu'a eue une version particulière.

Le même journal donne la cascade du 25 août : quatre « upgrade » en onze secondes,
etm12→etm10→etm4→etm8→etm9. L'état final est celui du dernier configuré, pas du plus récent.

Renvoi ajouté vers les deux chemins de déploiement désormais écrits (BUILD-WORKFLOW.md §8,
DEPLOY.md §8) — le premier ne décrivait que le parc, laissant le chemin du banc s'improviser.

Documentation seule : docs/ n'est pas embarqué dans le .deb (vérifié : le paquet ne contient que
le .so, le changelog, le copyright et les .qm). 1.15.2+etm14 reste donc valide et fidèle à sa
source ; pas de nouvelle version.

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

docs/RELEVE_LOTB.md

@@ -365,20 +365,40 @@ Le `docs/TEST_TERRAIN.md` de CE dépôt portait aussi la recette fautive — `sc
 > échouer la correspondance sudoers, et le déploiement ne passerait plus sans mot de passe. Le
 > contrôle vit donc dans le script, où il est en prime visible et journalisé.
 
-**Correction factuelle.** `+etm12` **n'est pas perdu**. Il est dans le dépôt APT, canal
-`powersync-nightly`, avec son binaire en pool :
+**Ce que `.75` est, et pourquoi ça change l'enjeu.** C'est le **banc de bêta-test** : on y pose
+un paquet **avant** de le publier, pour décider s'il mérite d'aller au canal. Conséquence — sur
+le banc, un paquet **pas encore publié** n'existe qu'à **deux** endroits, le répertoire de dépôt
+de la box et le pool local de build. Ni au dépôt APT, ni chez un client, ni dans aucun git : un
+`.deb` ne se versionne pas. **L'écraser est irréversible.** C'est cela, plus que le ramassage
+multiple, que le verrou d'archivage protège.
+
+**Ma première rédaction se rassurait à tort**, en constatant que `+etm12` était au canal donc
+que « `.75` était réparable à tout moment ». Le journal dpkg de la box donne la chronologie
+exacte, et elle dit l'inverse de ce que j'en avais tiré :
 
 ```
-$ reprepro -b /mnt/builddisk/apt-repo list powersync-nightly powersync-energy-plugin-nymea
-powersync-nightly|main|arm64: powersync-energy-plugin-nymea 1.15.2+etm12
-$ ls /mnt/builddisk/apt-repo/pool/main/p/powersync-energy-plugin-nymea/
-powersync-energy-plugin-nymea_1.15.2+etm12_arm64.deb
-powersync-energy-plugin-nymea-dbgsym_1.15.2+etm12_arm64.deb
+2026-08-13 19:48:59  upgrade  …:arm64  1.15.2+etm11 → 1.15.2+etm12    ← posé sur le BANC
+2026-08-13 20:48:58                                                    ← publié au pool, 1 h plus tard
+2026-08-25 10:50:22  upgrade  …:arm64  1.15.2+etm12 → 1.15.2+etm10  ┐
+2026-08-25 10:50:28  upgrade  …:arm64  1.15.2+etm10 → 1.15.2+etm4   │ quatre « upgrade »
+2026-08-25 10:50:32  upgrade  …:arm64  1.15.2+etm4  → 1.15.2+etm8   │ en ONZE secondes
+2026-08-25 10:50:33  upgrade  …:arm64  1.15.2+etm8  → 1.15.2+etm9   ┘
 ```
 
-Ce qui a été perdu, c'est **l'état déployé**, pas la version. `.75` était réparable depuis le
-dépôt APT à tout moment. Les canaux `stable` et `testing`, eux, ne contiennent aucun
-`powersync-energy-plugin-nymea` — c'est peut-être là qu'a porté le regard.
+Deux enseignements. Le premier : **l'état final est celui du dernier configuré, pas du plus
+récent** — dpkg ne trie pas, il déballe dans l'ordre où il rencontre les fichiers. Le second, et
+c'est celui qui compte : entre 19:48 et 20:48 le 13 août, `+etm12` n'existait **que** sur le
+banc. **Le risque ne dépend pas de la chance qu'a eue une version particulière** — la plupart
+des paquets de banc ne quittent jamais cette fenêtre, puisqu'ils sont écartés, c'est leur raison
+d'être.
+
+Pour mémoire, l'état du dépôt : `+etm12` est bien au canal `powersync-nightly` avec son binaire
+en pool (`reprepro list`, horodatage 13 août 20:48) ; `stable` et `testing` ne contiennent aucun
+`powersync-energy-plugin-nymea`.
+
+**Les deux chemins de déploiement sont désormais écrits** — banc par `deploy.sh`, parc par
+`apt` — dans `BUILD-WORKFLOW.md` §8 (qui ne décrivait que le second, laissant le premier
+s'improviser à la main) et `DEPLOY.md` §8.
 
 ### (b) `pac-terrain` — d'où elle vient, et ce que ça change pour l'app