docs: corriger la rotation de clé et poser le principe du store public

Deux corrections de direction, données par le PO — et les deux viennent de la
même erreur de méthode : avoir lu l'ÉTAT COURANT du source comme s'il donnait
l'INTENTION. C'est précisément ce que ce brief met en garde de faire.

1. Rotation de clé. La spec disait « qui n'est pas resté abonné perd l'accès »
   et demandait d'exposer une obligation d'abonnement au consommateur. Faux
   comme cible : quand une clé tourne, la nouvelle est envoyée dans l'inbox des
   ayants droit, et cette inbox est traitée automatiquement à la connexion
   suivante d'un client. L'accès n'est pas perdu, il est différé — cohérent avec
   le local-first. Donc rien à implémenter côté consommateur, et la re-livraison
   emprunte le même canal que la livraison initiale : le mécanisme de partage
   couvre les deux sans cas particulier.

2. Store public. Principe à exposer tel quel : un élément du store public est
   public — qui a l'URL lit le contenu — mais PAS récursivement. Un contenu
   public peut référencer du contenu privé sans donner accès au référencé. C'est
   la non-récursivité qui porte la valeur : elle permet un objet public pointant
   vers de l'identité privée, le cas exact du consommateur. NextGraph s'oriente
   par ailleurs vers un non-chiffrement du contenu public (données toujours
   signées) : détail d'implémentation dont la surface ne doit pas dépendre. Si le
   store public ne se comporte pas comme le principe le décrit, c'est le polyfill
   qui s'adapte, pas le consommateur.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg

docs/briefs/2026-07-20-caps-emulation-alignment.md

@@ -288,15 +288,29 @@ mais le chemin est `unimplemented!()` et le récepteur **jette** le cap reçu. L
 polyfill l'émule donc en attendant → fiche dans le bug-inbox, avec ce qu'il faudra
 en retirer le jour où l'amont l'implémente.
 
-### 4. La durabilité — exposer l'obligation, pas la masquer
+### 4. La rotation de clé — re-livraison automatique, pas perte d'accès
 
-Un cap partagé est **rafraîchissable** : après un refresh, qui n'est pas resté
-abonné **perd l'accès**. Le cap durable (`PermaCap`) n'existe pas encore.
+**CORRIGÉ le 2026-07-27 (direction confirmée par le PO).** Une version antérieure
+de cette section disait « qui n'est pas resté abonné perd l'accès » et demandait
+d'exposer une obligation d'abonnement. **C'est faux comme cible.** Le commentaire
+amont dont ça venait (« *if they don't subscribe, they will lose access after the
+refresh* ») décrit **l'état courant**, pas l'intention — l'erreur de méthode que ce
+brief met justement en garde de commettre.
 
-La surface ne doit donc **pas** promettre la permanence — sinon le consommateur
-n'implémente jamais « rester abonné ou perdre l'accès » et conserve silencieusement
-des caps morts. À exposer explicitement : un cap peut **expirer**, et une
-re-livraison arrive par le même canal que la livraison initiale.
+La **direction** : quand une clé tourne, la nouvelle est **envoyée dans l'inbox**
+des utilisateurs qui conservent le droit d'accès, et cette inbox est **traitée
+automatiquement** dès qu'un client de l'utilisateur se connecte.
+
+Conséquences pour la surface :
+
+- **Aucune obligation d'abonnement à exposer.** Le consommateur n'a rien à
+  implémenter pour « garder » un accès.
+- L'accès n'est pas perdu, il est **différé** jusqu'à la prochaine connexion —
+  cohérent avec le reste du modèle local-first.
+- Une re-livraison emprunte **le même canal** que la livraison initiale : l'inbox.
+  Donc le mécanisme de §3 couvre les deux, sans cas particulier.
+- La **révocation** reste ce qu'elle est : on cesse de re-livrer à qui ne doit plus
+  lire, et c'est non rétroactif.
 
 ### 5. Ce qui disparaît ou change de nom
 
@@ -310,13 +324,23 @@ re-livraison arrive par le même canal que la livraison initiale.
 | `resetCaps()` au changement d'identité | **basculer** de trousseau, **pas effacer** |
 | `PrincipalId` dans la surface caps | **sort** — on adresse des inboxes |
 
-### 6. L'exception publique, à ne pas raboter
+### 6. Le public — lisible par l'URL, et NON récursif
 
-Un lien de repo **public** n'a **pas** de read_cap : le cap se télécharge depuis
-l'outer overlay. Pour du contenu public, la forme cible **est** donc bien
-« référence nue → contenu ». L'invariant du §2 admet cette exception — elle n'est
-pas une entorse, c'est un second mécanisme. *(Type sans consommateur en amont :
-DIRECTION, pas mécanisme vérifié.)*
+Principe cible (confirmé par le PO, 2026-07-27), à exposer tel quel :
+
+> **Un élément du store public est public : qui a l'URL lit le contenu.**
+> Mais **pas récursivement** — un contenu public peut *référencer* du contenu
+> privé, et la référence ne donne pas le contenu référencé.
+
+C'est un **second mécanisme** à côté de la possession de clé du §2, pas une
+entorse à l'invariant. Et c'est la non-récursivité qui porte la valeur : elle
+permet un objet public qui **pointe** vers de l'identité privée — le cas exact du
+consommateur.
+
+*Détail d'implémentation à ignorer côté forme* : NextGraph s'oriente vers un
+**non-chiffrement** du contenu du store public (les données restant signées). La
+surface ne doit pas en dépendre. **Si le store public ne fonctionne pas** comme ce
+principe le décrit, c'est **le polyfill** qui s'adapte — pas le consommateur.
 
 ### 7. Recette de P1a — vérifiable sans une ligne de crypto