docs: réécrire P1a après double revue adverse, corriger le verdict Q1 sur-lu

Deux adversaires à mandats disjoints (alignement NextGraph / économie
conceptuelle). Résultat : P1a fond de 8 notions nouvelles à 2, et un fait que
j'avais consigné comme VÉRIFIÉ était sur-lu.

CORRECTION DE FOND — le fetch keyless n'est PAS constructible. Le spike P0
concluait « Q1 OUI partiel, seul garde : l'overlay ». Il s'arrêtait au contrôle
d'accès sans regarder l'ADRESSAGE : aucune commande d'existence au niveau SDK ;
la seule sonde est interne au crate, exige des BlockId ET un repo chargé, et vise
l'overlay inner dérivé du secret de lecture. Une référence cap-less porte un
RepoId et l'overlay outer — ni BlockId, ni le bon overlay. L'adressage
présuppose le cap. Note corrigée sur place (pas empilée), avec la leçon
transposable : vérifier qu'une garde laisse passer ne prouve pas qu'une
opération est atteignable — encore faut-il pouvoir NOMMER ce qu'on demande.

P1a réécrite :
- UN seul type nouveau, `ReadCap`, le nom de l'amont. `Nuri` reste ce qu'il est
  déjà (~90 usages) : la forme cap-less. Les types de marque disparaissent — le
  SDK réel prend `nuri: String` et enforce au RUNTIME par la crypto ; une
  garantie de compilation est un concept que NextGraph n'a pas, et un
  consommateur qui typerait tout devrait dé-typer plus tard.
- `capFor(nuri) → ReadCap | undefined` : le trousseau. Comble un trou fatal du
  premier jet — `doc_create` renvoie un NURI cap-less, donc l'invariant « on ne
  va jamais d'une référence nue à un cap » empêchait le créateur d'obtenir le cap
  de son propre document. Le trousseau existe déjà : la branche de store, où
  chaque création commite AddRepo{read_cap}. En amont c'est le wallet.
- `shareCap(cap, toInbox)` : on partage UN DOCUMENT, à une ou plusieurs inboxes.
  Pas le store — donner un cap de store livrerait tout son contenu présent et
  futur. Les caps reçus arrivent comme dépôts d'inbox, consommés par le
  inbox.watch existant (ce qui règle le point 7 de la revue adverse).
- Durabilité : ne PAS la promettre. Verbatim amont, les caps sont « not durable »
  et qui ne reste pas abonné perd l'accès ; PermaCap est un TODO. La surface doit
  exposer l'obligation d'abonnement, sinon le consommateur retient des caps morts.
- `PrincipalId` sort de la surface caps : n'existe pas en amont, et le brief le
  supprimait de canRead en le qualifiant d'inversion ACL avant de le réintroduire
  dans sealCapTo. On adresse des inboxes, comme inbox.post le fait déjà.
- Section 0 conservant les erreurs du premier jet : elles sont instructives.
- Exception publique actée : un lien de repo public n'a PAS de read_cap (il se
  télécharge depuis l'outer overlay) — pour du public, « référence nue → contenu »
  est bien la forme cible.

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

docs/readcap-and-nuri-model.md

@@ -133,10 +133,28 @@ client↔broker et le stockage local utilisent l'**inner** — valeur différent
 tirée du store elle aussi, donc la propriété tient dans les deux cas. Un store
 `Dialog` renvoie un `Inner`, toujours store-scopé.
 
-INFÉRÉ : un détenteur **sans clé** peut vraisemblablement **récupérer les blocs
-chiffrés** (avec l'overlay, toujours cap-less) → vérifier l'**existence** d'un doc
-sans lire son **contenu**. Le chemin d'autorisation de fetch broker pour un
-détenteur sans clé n'a **pas** été tracé — à confirmer avant de s'en servir.
+**CORRIGÉ le 2026-07-27 — cette hypothèse était FAUSSE.** On avait inféré, puis
+cru vérifier, qu'un détenteur **sans clé** pouvait récupérer les blocs chiffrés et
+donc prouver l'**existence** d'un document. Une revue adverse a montré que le
+raisonnement s'arrêtait au *contrôle d'accès* sans regarder l'**adressage** :
+
+- Il n'existe **aucune commande d'existence au niveau SDK**.
+- La seule sonde (`BlocksExist`) est **interne au crate**, exige des `BlockId`
+  **et** un repo déjà **chargé**, et adresse l'overlay **inner** — lequel est
+  dérivé du **secret de lecture**.
+- Une référence cap-less porte un RepoId et l'overlay **outer** : aucun `BlockId`
+  à sonder. Et l'outer n'est de toute façon jamais enregistré (`expose_outer`
+  codé en dur à `false`, sans paramètre SDK).
+- Le seul primitif accessible à un non-membre (`ExtObjectGet`) exige les ObjectIds
+  **et leurs clés**.
+
+> **L'adressage lui-même présuppose le cap.** Prouver l'existence d'un document
+> sans détenir sa clé n'est pas constructible aujourd'hui, et rien n'indique que
+> ce soit prévu.
+
+Leçon transposable : vérifier qu'une garde d'accès **laisse passer** ne prouve pas
+qu'une opération est atteignable — encore faut-il pouvoir **nommer** ce qu'on
+demande.
 
 ## 5. Ce que le polyfill émule (caps.ts) — et où ça diverge