docs: l'inbox par document n'est pas une anticipation, c'est une capacité du moteur

Glissement à corriger : de « le moteur ne le FAIT pas » (vrai) j'ai conclu
« c'est notre anticipation » (faux). Le moteur le PERMET, et de façon générique
par conception :

- `inbox: Option<PrivKey>` est un champ de TOUT `Repo` (`repo.rs:126`), pas
  d'une structure de store ;
- `AddInboxCapV0` est clé par `repo_id` — « Repo the Inbox is opened for » ;
- `update_inbox_cap_v0` l'applique via `self.repos.get_mut(repo_id)` sans
  AUCUNE vérification `is_store` (`verifier.rs:1920`) ;
- et à tout moment, `AddInboxCap` étant un commit de branche User dont le type
  documente le cas de mise à jour.

Ce qui est vrai est plus étroit : aucun chemin de code n'en CRÉE une pour un
document. « Ne fait pas » n'est pas « ne peut pas » — c'est précisément
l'interdit que ma propre règle pose, et je l'ai enfreint en le formulant.

Donc l'inbox par document s'aligne sur le modèle du moteur (niveau 1) ; ce qui
est de nous est la surface JS, aucune n'étant exposée aux niveaux 2 et 3.
Corrigé dans store-registry.ts, nextgraph-current-state.md et les deux briefs.

packages/client/src/store-registry.ts

@@ -1099,28 +1099,21 @@ export async function userStoreDoc(id: string, scope: Scope): Promise<Nuri> {
  * same branch that carries `AddLink`. So "which inboxes may I read" is answered by the
  * User branch, and that is what this emulates.
  *
- * **This ANTICIPATES: no document has an inbox upstream today.** `new_store_default`
- * attaches one only `if !private` (`engine/verifier/src/verifier.rs:2994`), and
- * `doc_create` goes through `new_repo_default`, which leaves `inbox: None`
- * (`engine/repo/src/repo.rs:574`) — the only two `AddInboxCap` commits in the engine
- * are for the public and protected STORE repos (`engine/verifier/src/site.rs:128,149`).
- * What is verified is the SHAPE: the record is keyed by `repo_id`, so it accommodates
- * an inbox on any repo. What is not verified is that anything upstream will create one
- * per document. At migration this either becomes native or stays emulated here; either
- * way the consumer-facing act is unchanged.
+ * **The engine SUPPORTS this; nothing exercises it automatically.** Those are two
+ * different statements, and conflating them is what made an earlier version of this
+ * comment call the feature an "anticipation". It is not. `inbox: Option<PrivKey>` is a
+ * field of EVERY `Repo` (`engine/repo/src/repo.rs:126`), not of a store structure;
+ * `AddInboxCapV0` is keyed by `repo_id` (`engine/repo/src/types.rs:1973`); and
+ * `update_inbox_cap_v0` applies it with `self.repos.get_mut(repo_id)` and **no
+ * `is_store` check of any kind** (`engine/verifier/src/verifier.rs:1920`). Generic by
+ * construction, and at any time (see the User-branch note above).
  *
- * **Callable at ANY time, not only at creation — and that is the faithful shape.**
- * `AddInboxCap` is a User-branch commit (`CommitBody::on_user_branch`,
- * `engine/repo/src/commit.rs:1043-1050`), i.e. an entry in a stream that stays open over
- * time, and its type documents the late case explicitly: *"DEPS to the previous
- * AddInboxCap commit(s) if it is an **update**. in this case, repo_id should match"*
- * (`engine/repo/src/types.rs:1969-1971`). The verifier applies it to an already-loaded
- * repo (`update_inbox_cap_v0` → `repo.inbox = Some(...)`, `verifier.rs:1920`). That
- * `new_store_default` attaches the two STORE inboxes at site creation is how those two
- * happen to be made — not a constraint that an inbox may only exist from birth. So do
- * NOT "simplify" this into a `createEntityDoc(…, { withInbox })` flag: it would narrow
- * the model, and an owner deciding later that a document should receive is a case the
- * engine supports.
+ * What is true is narrower: no code path CREATES one for a document — `new_store_default`
+ * attaches one only `if !private` (`verifier.rs:2994`), `doc_create` leaves `inbox: None`
+ * (`repo.rs:574`), and the only two `AddInboxCap` commits in the engine are for the
+ * public and protected STORE repos (`engine/verifier/src/site.rs:128,149`). So the
+ * capability exists and is simply unexposed above level 1: this function is aligned on
+ * the engine's model, it does not bet past it.
  *
  * Lazy on purpose, for the same reason: creating an inbox document for every entity up
  * front would double every `createEntityDoc` for inboxes most documents never receive