docs(hermes-tt): runbook elem_id OWA volatile (piste message_id natif fermee) + PROTOCOL-INFRA

- hermes-tt/nyora-notes-tt-message-id-elem-id-volatile-08-08-2026.md : cycle complet --
  hypothese elem_id stable, test insuffisant (1 msg position 0, appels rapproches) qui l'a
  faussement valide, test rigoureux (19 msg, ensembles disjoints, 0/20 meme index) qui
  l'infirme, cause (id de rendu DOM volatile), decision (message_id reste hash SHA256 stable,
  conservation conversation_id data-convid niveau thread + fix retry /search count:0), garde-fou
  dedup (399 notes en dossiers 'done' jamais re-scannes -> pas de doublon).
- PROTOCOL-INFRA.md : regle "id DOM d'un SPA jamais presume stable" (tester >=2 rendus reels +
  plusieurs echantillons) + fix /search count:0 transitoire + piege split('|') sur attrs.
- _INDEX.md : entree ajoutee.

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

common/PROTOCOL-INFRA.md

@@ -216,3 +216,27 @@ Tous les tools MCP RAG mail cassaient juste apres chaque backup n8n (toutes les
 ## FIX -- cron n8n orphelin, boucle infinie sur statuts finaux (error_409/404), cause reelle instabilite hermes-mail-browser (2026-08-02)
 
 Workflow n8n 'nyora-notes-tt -- Ingestion continue' actif depuis le 31/07, toutes les 10 min (292 executions), en boucle sur les memes dossiers error_409/error_404 -- statuts FINAUX (jamais retraitables avec succes), donc sa condition d'arret 'automatique quand tout est done' ne se declenchait jamais. `neverError:true` sur le noeud HTTP masquait le probleme (292/292 executions n8n 'success' malgre des 409 systematiques). Consequence : contention reguliere sur la page Playwright partagee de hermes-mail-browser, prise a tort pour de l'instabilite structurelle OWA. Desactive (unpublish_workflow). Verifie ensuite : hermes-mail-browser sain (RAM/CPU), timings /search et /message/attachments conformes aux baselines deja documentees une fois le bruit de fond supprime. Reflexe a generaliser : toute boucle n8n a condition d'arret basee sur un etat DB doit distinguer statut final vs statut retry-able, sinon elle ne se videra jamais ; et `neverError:true` cache ce genre de boucle inutile au monitoring standard n8n -- verifier le contenu des reponses, pas juste le statut d'execution. Avant de blamer un service externe pour de la lenteur persistante, chercher d'abord un consommateur interne recurrent via `docker logs` filtre par IP source. Detail : hermes-tt/n8n-cron-orphelin-hermes-mail-browser-instabilite.md.
+
+## REGLE -- id DOM d'un SPA (OWA/React) : jamais presume stable, tester sur plusieurs rendus + plusieurs echantillons (2026-08-08)
+
+Un attribut `id=`/`data-*` scrape sur une ligne d'un SPA n'est PAS presume stable dans le temps.
+Cas nyora-notes-tt : `elem_id` (attribut `id` de ligne OWA), exploite comme `message_id` natif,
+s'est revele VOLATILE -- OWA/React regenere un GUID frais a chaque rendu (test rigoureux : 0/19
+messages stables entre deux appels /search identiques, ensembles d'id disjoints, meme index -> id
+different ; l'ordre de liste est stable mais pas l'id, `aria-posinset` non peuple). Un premier test
+a 1 seul message toujours en position 0 sur appels rapproches l'avait faussement valide (le DOM
+n'etait pas re-rendu entre les appels -> meme id volatile reutilise). Reflexe : pour juger la
+stabilite d'un id DOM, faire >= 2 rendus REELS distincts (appels espaces OU requetes forcant un
+re-render), sur PLUSIEURS elements, apparier par une identite externe stable (ex. texte de la ligne)
+et verifier le RECOUVREMENT D'ENSEMBLES -- jamais un seul echantillon en position fixe. Seul
+`data-convid` (ConversationId Exchange, niveau THREAD) est stable cote ligne OWA ; aucun id natif
+par-message n'est expose par le scraping DOM. Detail : hermes-tt/nyora-notes-tt-message-id-elem-id-volatile-08-08-2026.md.
+
+## FIX -- /search hermes-mail-browser : count:0 transitoire sur appels rapproches (2026-08-08)
+
+Deux appels `/search` a < ~10 s d'ecart : le 2e renvoie parfois `count:0` (liste virtualisee OWA pas
+encore stabilisee cote Playwright). Fix cote client (`hermes_mail_client.search_folder`) : si `items`
+est vide de facon inattendue, retry UNIQUE apres `time.sleep(4)` avant d'abandonner (simple, pas de
+backoff). Piege de parsing associe : `attrs` (string pipe-delimitee) reinjecte `aria-label` en fin de
+chaine (texte libre non echappe, `|` et sauts de ligne possibles) -> NE JAMAIS `split('|')` global ;
+extraire par regex ciblee (`data-convid=([^|]+)`, base64 sans `|`). Detail : meme runbook ci-dessus.