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.

docs/nextgraph-current-state.md

@@ -121,11 +121,19 @@ documents, and not the private store. `new_store_default` attaches one solely `i
 `AddInboxCap` commits in the whole engine are the two in `engine/verifier/src/site.rs:128,149`
 — one for the public store repo, one for the protected one.
 
-The *register* is nonetheless per-repo: `AddInboxCapV0 { repo_id, overlay, priv_key }`
-(`engine/repo/src/types.rs:1973`) records **which repo** an inbox is opened for, so the
-shape accommodates an inbox on any repo. Nothing creates one, which is a different
-statement from the shape forbidding it — and it is why this lib's per-document inbox is
-an ANTICIPATION of that shape, not an emulation of something upstream already does.
+**But the engine SUPPORTS an inbox on any repo — "does not" and "cannot" are different
+statements.** `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`) — *"Repo the Inbox is opened for"*. And
+`update_inbox_cap_v0` applies it via `self.repos.get_mut(repo_id)` with **no `is_store`
+check of any kind** (`engine/verifier/src/verifier.rs:1920`). It is generic by
+construction, and available at any time: `AddInboxCap` is a User-branch commit
+(`engine/repo/src/commit.rs:1043-1050`) whose type documents the late case — *"DEPS to
+the previous AddInboxCap commit(s) if it is an update"*.
+
+So a per-document inbox is **not an anticipation**: it is an engine capability that no
+code path exercises automatically and that no level-2 or level-3 API exposes. This lib
+implements it aligned on the engine's model.
 
 A non-editor can deposit into an inbox without being invited as an editor; the owner
 moderates. NURI: `did:ng:d:<inbox_id>`. Content: the `InboxMsgContent` enum (`ContactDetails`,