v3 : relecture de 7ffa4fd — un refus du nœud lâche le bulletin, le reçu ne dit vérifié que ce que scelle l'empreinte

polkadot-api lève InvalidTxError (JSON indenté) quand le nœud refuse la transaction :
elle est désormais lue comme « la chaîne a dit non » (rien n'est parti, le bulletin est
lâché), au lieu de rester en attente 24 h. La page /bulletins ne présente comme vérifiés
que la version, la révision et le choix ; l'article, le titre et le bloc du reçu sont dits
hors du sceau. ADR 0008 : trois affirmations corrigées (indexeur sans filtre, débit de la
tâche de fond, lectures qui n'utilisent pas encore shown_tally).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/adr/0008-vote-par-transaction.md

@@ -117,8 +117,10 @@ le dernier bloc définitif traité. Relevé le 2026-10-31 sur indexer.duniter.or
 3 407 342 contre 3 407 345…), les 2 à 3 blocs de la finalité de Duniter v2. Seul un commentaire
 d'un bloc ≤ `height` compte, ou refuse ; au-dessus, le bulletin attend.
 
-Le moteur (`ld_engine::ballot::judge`) juge à nouveau ce qui revient — un indexeur qui ignore le
-filtre ne change que le nombre de pages. Il garde le premier commentaire, dans l'ordre de la
+Le moteur (`ld_engine::ballot::judge`) juge à nouveau ce qui revient. Un indexeur qui ignorerait
+le filtre ne change d'abord que le nombre de pages, mais au-delà de 1 000 copies nues placées
+avant le vrai commentaire (20 pages de 50), celui-ci n'est plus lu et le bulletin reste en attente
+(relecture de `7ffa4fd`) : cas théorique, un PostGraphile sans ce filtre répond par une erreur. Il garde le premier commentaire, dans l'ordre de la
 chaîne, qui n'est pas une copie : pour un bulletin lié, un commentaire d'un autre compte est une
 copie ; pour un bulletin Ğecko, **un commentaire sans le virement est une copie** (une remarque
 seule ne coûte rien à envoyer). Puis il exige :
@@ -138,8 +140,9 @@ autre session ne voit jamais ce qu'a voté la même identité ailleurs.
 **La tâche de fond** passe toutes les 10 secondes et lit **50 bulletins en attente au plus, le
 moins récemment lu d'abord** (jamais lu, puis la plus ancienne lecture) : chaque bulletin en
 attente est lu au moins toutes les ⌈n / 50⌉ passes, que la page l'attende ou non (un code Ğecko,
-une fenêtre fermée). Il faudrait plus de 430 000 bulletins en attente pour qu'un seul ne soit pas
-lu dans ses 24 heures. La page, elle, fait lire son bulletin au plus toutes les 3 secondes.
+une fenêtre fermée). Une lecture de l'indexeur prend 0,5 à 2,1 s (mesuré le 31/10), donc une passe
+de 50 bulletins dure 25 à 100 s : il faudrait de l'ordre de 40 000 à 170 000 bulletins en attente
+pour qu'un seul ne soit pas lu dans ses 24 heures. La page, elle, fait lire son bulletin au plus toutes les 3 secondes.
 
 Un bulletin non vu en **24 heures** est **lu une dernière fois à son échéance**, puis lâché ;
 s'aucun indexeur ne répond, ou si son commentaire attend un bloc définitif, il reste en attente
@@ -201,7 +204,9 @@ Recoupée avec les totaux affichés en direct, la chaîne peut laisser deviner u
 qui bouge juste après un vote) : une décision d'Yvv attend (secret par paliers, ou totaux en
 direct). En attendant, les totaux affichés passent par une seule fonction,
 `DocState::shown_tally` (et `shown_evaluation`), où une publication par paliers se branchera ;
-l'adoption lit `tally`, et les textes publiés (`publish.rs`) suivraient `shown_tally`.
+l'adoption lit `tally`. Deux lectures n'y passent pas encore et lisent les totaux en direct :
+l'aperçu des propositions bien cotées (`docs.rs`, `unit_states` et `proposal_states`) et les
+textes publiés (`publish.rs`). Elles s'y brancheront avec la décision d'Yvv.
 
 ### Ce que sait le serveur