v3 : points de la relecture indépendante — une personne une voix, ordre de déploiement, durcissements

- Dans Monnaie libre (électorat = toile de confiance), seuls les membres de la
  toile votent (trustin_access::votes_in) ; une identité d'invitation y lit,
  propose et signale. L'interface le dit à la place des boutons (fr/en/es).
- Un lien d'invitation ne vise jamais une identité Ğ1 ; le lien est réservé
  avant de créer l'identité (deux acceptations simultanées : une seule passe).
- Un nombre n'est jamais une coquille (« 50 » → « 5,0 », « 1 5 » → « 15 »).
- Redirection après connexion : caractères de contrôle refusés.
- En-têtes : X-Frame-Options DENY, frame-ancestors 'none', nosniff, Referrer-Policy.
- Déploiement : le produit passe en premier ; la maquette attend son succès.
  Les conteneurs, même arrêtés, qui revendiquent encore la racine sortent de
  « restart: always » (ils reviendraient au redémarrage de Docker).
- Tests : 57 Rust (dont 14 scénarios d'API), e2e 12 / 12 avec C11.

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

docs/adr/0006-acces-connect-trustinwallet.md

@@ -13,6 +13,9 @@ Duniter peut se loger et tout faire — sauf la gestion des accès », qui revie
   en-tête anti-CSRF sur toute écriture.
 - Les règles (qui voit, qui ouvre, qui administre) vivent dans `trustin-access`, futur cœur du
   service trustinWallet ; le serveur ne décide jamais seul.
+- **Une personne, une voix** : là où l'électorat est la toile de confiance (Monnaie libre),
+  seuls ses membres votent ; une identité d'invitation y lit et propose. Un nouveau lien ne
+  vise jamais une identité Ğ1 (un administrateur ouvrirait une session à sa place).
 - Premier administrateur : un lien d'invitation écrit au premier démarrage dans le volume de
   données (0600), jamais dans les journaux.