docs: l'overlay est store-scopé ; retrait de la fausse piste "membership"

readcap-and-nuri-model — nouvelle section sur l'OVERLAY, le concept qui
manquait à la référence. C'est l'espace réseau d'un STORE : deux formes
(outer = BLAKE3 public du store_id, calculable par tous ; inner = BLAKE3 keyed
par le ReadCapSecret, réservé aux détenteurs de la clé). Le `✌️` d'un NURI de
DOCUMENT porte l'overlay de son store — VÉRIFIÉ de bout en bout, avec une
contre-preuve mécanique : dans Store, get/put/del/has passent tous
`&self.overlay_id`, donc tous les documents d'un store partagent le namespace
de blocs et un overlay par-document est structurellement impossible.

Conséquence documentée, qui contraint tout modèle de présence anonyme : le
`✌️` est un pseudonyme stable et permanent de la personne, présent dans toute
référence cap-less vers n'importe lequel de ses documents protected. Le même
bit d'information sert à dédupliquer sans lire ET à tracer — indissociables.

vision — correction d'une forme fausse. Le document affirmait « écriture =
membership/permissions », en miroir de « lecture = possession de clé ». Faux :
il n'y a pas de notion d'appartenance dans le modèle, uniquement des clés et
des URLs. Toute forme en member/role/permission est une MAUVAISE forme.

brief caps — la section « périmètre élargi : WriteCap = membership » est
retirée, conservée barrée comme garde-fou, avec la leçon de méthode qui vaut
plus qu'elle : lire l'état courant de nextgraph-rs pour en DÉDUIRE la forme
cible est une erreur — le source contient de l'échafaudage inerte (AddMember,
PermissionV0, verify_sig jamais appelé hors tests). Le source sert à vérifier
un mécanisme, jamais à inférer une intention.

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

@@ -62,6 +62,79 @@ que la vision interdit. **Fermer ces voies = le cœur de P1.**
 5. **Révocation = re-key** émulé : invalider l'ancien token, re-livrer un nouveau
    aux autorisés restants ; **non-rétroactif**.
 
+## ~~Périmètre élargi : le WriteCap (= membership)~~ — RETIRÉ (2026-07-21)
+
+**Cette section était fausse et est conservée barrée comme garde-fou.** Elle
+importait une notion de *membership* lue dans l'**état courant** de `nextgraph-rs`
+(`AddMember`, `PermissionV0`, `member_pubkey`) et la promouvait en **forme cible**.
+Or (a) ces types sont un **échafaudage inerte** au runtime — `verify_sig` /
+`verify_perm` ne sont appelés que dans des tests unitaires, les `Repo` sont
+construits avec `members: HashMap::new()` ; et (b) le modèle cible **n'a pas de
+notion d'appartenance du tout** : uniquement des **clés et des URLs**, symétrique
+et asymétrique. Une forme en `member`/`role`/`permission` est donc exactement la
+**mauvaise forme** que ce brief existe pour empêcher.
+
+**La leçon de méthode, qui vaut plus que la section retirée** : lire l'état
+courant de NextGraph pour en **déduire** la forme cible est une erreur — l'état
+courant contient de l'inachevé qu'il ne faut pas figer dans le polyfill. Le source
+sert à vérifier un **mécanisme** existant, jamais à inférer une **intention**.
+
+Contenu erroné conservé ci-dessous à titre de trace :
+
+<details>
+<summary>Section retirée</summary>
+
+**Pourquoi c'est ici et pas ailleurs.** Le brief était d'abord centré ReadCap ; un
+constat adverse a montré qu'il **ne compose pas** avec son consommateur : le brief
+Festipod « inscriptions par Set » a besoin de **dédupliquer** les participations
+(un user = une participation par événement), et la seule base non-applicative
+disponible est la **signature d'auteur du commit** — donc un primitif d'**écriture**,
+pas de lecture. Un polyfill qui n'expose que la forme du ReadCap laisse le
+consommateur inventer sa propre dédup applicative → exactement la mauvaise forme.
+
+**La forme réelle (VÉRIFIÉE, cf. `readcap-and-nuri-model.md` §1)** — et elle est
+**asymétrique** de la lecture, ce qui est le point le plus facile à rater :
+
+- **Lecture = possession d'une clé.** Pas d'ACL. Qui détient, lit.
+- **Écriture = membership + permissions** (`AddMember`, `AddPermission` sur le
+  `RootBranch`). C'est **bel et bien une liste d'autorisation** — pas de la
+  possession. Émuler l'écriture « par possession de token » serait aussi faux que
+  l'ACL de lecture actuelle, en miroir.
+- **Les commits SONT signés** par un `UserId` (clé **technique**, distincte du
+  profil) — donc un identifiant de dédup **existe** nativement, sans pseudonyme
+  applicatif.
+- **Mais vérifier une signature exige d'être membre du repo** (accès au
+  `member_pubkey`). Un tiers non-membre voit un commit signé sans pouvoir
+  l'attribuer.
+- **Le dépôt d'inbox n'est PAS authentifié** (sealed box anonyme) : un `from`
+  déclaré est du contenu, pas une preuve.
+
+**Ce que ça impose au polyfill.** Exposer `membership` comme primitif **distinct**
+de la possession de cap, avec au minimum : ajouter/retirer un membre d'un repo,
+lire la members map **quand on est membre**, et **vérifier l'auteur d'un commit**
+(→ un digest d'auteur, **par-overlay donc par-store**). C'est ce dernier point qui
+débloque la dédup côté Festipod.
+
+**La conséquence de forme, à documenter explicitement** (sinon le consommateur se
+trompe de modèle) : le digest d'auteur étant **par-store**, le choix du découpage
+en stores **est** le choix du niveau de corrélation. Un store **stable par-user**
+donne un identifiant traçable **cross-événement** ; un store **par-événement**
+donne un pseudonyme **local à l'événement** — dédup possible, corrélation
+impossible. Festipod a besoin du second. Le polyfill doit donc rendre ce découpage
+**exprimable**, pas le figer.
+
+**Reste ouvert** : « le créateur d'un événement peut-il être membre du store qui
+contient les participations, sans pour autant en détenir la clé de lecture ? » —
+c'est-à-dire membership (écriture/vérification) et possession (lecture)
+réellement **orthogonales**. Si NextGraph les couple, la dédup vérifiée et
+l'anonymat s'excluent, et c'est le brief Festipod qui doit trancher ce qu'il
+sacrifie. **À vérifier avant de façonner l'API.**
+
+</details>
+
+*(Question devenue sans objet : il n'y a pas de membership. La dédup ne passe pas
+par une vérification de signature — voir le brief Festipod « inscriptions ».)*
+
 ## Questions ouvertes
 
 - **TRANCHÉ (directive PO, 2026-07-21)** : on **simule la crypto** (donnée chiffrée
@@ -91,14 +164,39 @@ que la vision interdit. **Fermer ces voies = le cœur de P1.**
 **Livrable** : YES/NO/PARTIAL par Q1/Q2/Q3 + le primitif exact (file:line) + la forme d'API à exposer (si OUI), ou le constat que le compteur change (si NON).
 **Décision gatée** : OUI → P1 ; NON → le brief inscriptions revoit le compteur (pas anonyme, ou autre primitif).
 
+### Verdict du spike (2026-07-21) — VÉRIFIÉ dans `nextgraph-rs`
+
+| | Réponse | Preuve |
+|---|---|---|
+| **Q1 — existence/fetch sans cap** | **OUI, partiel** | Les lectures ne sont pas cap-gatées : `blocks_get.rs`, `blocks_exist.rs`, `topic_sync_req.rs` servent les blocs sans exiger ReadCap ni membership. **Seul garde : l'overlay**. Nuance non levée : overlay *inner* vs *outer* (`expose_outer`, défaut `false`) — **sonde en cours**. |
+| **Q2 — détecter une suppression sans clé** | **NON** | Broker append-only ; une suppression est un **commit tombstone chiffré** (`RemoveRepo`), no-op côté verifier. Sans clé on observe « une activité », jamais « une suppression ». |
+| **Q3 — confidentialité** | **OUI** | Blocs stockés en ciphertext ; la clé est `#[serde(skip)]` (`types.rs`), dérivée du `ReadCapSecret`. Le keyless ne donne **jamais** le contenu. |
+
+**Ce que ça décide.**
+- **P1 est débloqué** : `resolveCapLess(nuri) → { exists }` est la bonne forme — mais **`{ exists | deleted }` ne l'est PAS**. Ne pas exposer d'état `deleted`, ce serait inventer une capacité que la cible n'aura jamais (précisément le mode d'échec que ce brief combat).
+- **Le retrait doit être un message, pas une observation.** Côté consommateur : un *nudge* explicite. Le polyfill n'a **rien** à émuler pour ça — juste à ne pas prétendre le contraire.
+- **Reste gaté** : la nuance d'overlay (Q1). Si un non-membre ne peut pas rejoindre l'overlay d'un store *protected* tiers, le fetch keyless est inatteignable **en pratique** malgré un chemin d'autorisation ouvert — et le compteur anonyme retombe sur du déclaratif.
+
 ## Esquisse de phases
 
 - **P1** — distinction cap-less / cap-porteur dans les NURI + le read-model
-  (résoudre un cap-less = nommer/compter, pas lire).
+  (résoudre un cap-less = nommer/compter/prouver l'existence, **pas** lire, **pas**
+  de `deleted`). Inclut la **fermeture des bypass** (`inbox.read`, `sparqlQuery`)
+  sans laquelle la distinction n'est pas tenue.
 - **P2** — remplacer l'ACL par un modèle de **possession de token** (grant = livrer
-  à un destinataire ; enforcement = possession).
+  à un destinataire ; enforcement = possession). *Requalifié par la revue adverse :
+  le vrai contenu de P2 est **durabilité + cap-less + re-partage par le détenteur**,
+  pas « inverser l'ACL » — sans crypto, inverser ne produit aucun delta observable.*
 - **P3** — révocation par re-key (invalidation + re-livraison, non-rétroactive).
-- **P4** — adapter l'API consommateur + `migration-guide.md`.
+- **PW** — **WriteCap = membership** : primitif distinct (add/remove member,
+  members map lisible par un membre, **vérification d'auteur de commit** → digest
+  par-store), et découpage en stores **exprimable** par le consommateur.
+  *Indépendant de P1–P3 ; **bloquant pour la dédup Festipod**, donc à ordonnancer
+  tôt si c'est ce besoin-là qui presse.*
+- **P4** — adapter l'API consommateur + `migration-guide.md`. *La revue adverse
+  requalifie ce lot : ce n'est pas un swap d'API mais une **re-architecture
+  consommateur** (le grant se déplace vers l'acceptation de connexion et devient
+  persistant ; `declareConnections` disparaît).*
 
 ## Revue adverse (2026-07-20) — à intégrer