docs: inbox_post_link est notre nom, pas une API NextGraph annoncée

Le symbole n'existe nulle part dans `nextgraph-rs`, et aucune méthode de
`@ng-org/web` ne contient « inbox ». Il vient de notre propre plan de fork
(`docs/fork-inbox-fallback.md:32` — « expose `pub async fn inbox_post_link` »),
d'où il a essaimé dans huit autres endroits, cité comme une API « proposed/
future » de NextGraph. Une proposition interne devenue un fait par répétition —
le même mécanisme que « chaque document a une inbox native » et que l'inbox
mutualisée.

Corrigé partout sauf dans le plan de fork, où le nom est légitime puisque c'est
lui qui le propose. Et l'énoncé exact est désormais posé : on ne connaît NI le
nom NI la forme de la future surface JS pour les inbox — ce n'est pas
« non implémenté », c'est inconnu.

Ce qui est réellement vérifié côté moteur : `AppRequestCommandV0::InboxPost`
existe et `AppRequest::inbox_post()` le construit, mais le request_processor n'a
aucun arm pour lui — l'envoyer ne déclenche rien. Le seul dépôt qu'un client JS
peut provoquer aujourd'hui passe par `import_contact_from_qrcode`, qui appelle
`post_to_inbox(InboxPost::new_contact_details(...))` avec `with_readcap = false`
— la variante `true` étant `unimplemented!()`.

packages/client/docs/sdk-reference.md

@@ -297,7 +297,7 @@ from the reactive contract:
    deposit), so `inbox.watch` ([`../src/inbox.ts`](../src/inbox.ts)) **polls** via
    `setInterval` (default 1s) instead of subscribing. The finished contract is push
    (the broker already routes the inbox natively); these become subscriptions when the
-   sealed-inbox path (`inbox_post_link`) lands.
+   sealed-inbox path is exposed to JS (no such method exists today).
 
 3. **No cross-wallet / on-demand repo open.** There is no JS primitive to sync an
    *unknown* repo by NURI+ReadCap today (`load_repo_from_read_cap` is `pub(crate)`,

packages/client/src/inbox.ts

@@ -10,15 +10,17 @@
  * In real NextGraph, a message is sealed to the recipient's key and queued into
  * their inbox; the recipient's own verifier unseals each queued message and
  * applies it inline as it processes the inbox — there is no separate curator
- * process. A future `inbox_post_link` is the intended way to seal a link into an
- * inbox from the sender side; it is not exposed yet.
+ * process. There is NO sender-side JS call for this today: the verifier has no
+ * `InboxPost` arm and `@ng-org/web` exposes no inbox method at all. (`inbox_post_link`,
+ * named elsewhere in these docs, is OUR proposal from `docs/fork-inbox-fallback.md` —
+ * no such symbol exists in `nextgraph-rs`. Do not cite it as a planned API.)
  *
  * Here, on one shared wallet where everything is readable, both sides run in-lib:
  *   - `post` appends a deposit `{ from, payload, ts }` as RDF into the inbox
  *     document (in the shared wallet) via the `docs.sparqlUpdate` primitive;
  *   - `read` / `watch` read the deposits back via `docs.sparqlQuery` and expose
  *     them. This in-lib read stands in for the recipient's own inbox processing
- *     until the sealed-inbox path (`inbox_post_link`) is available.
+ *     until a sealed-inbox path is exposed to JS.
  *
  * All NextGraph I/O routes through the `docs` primitives (the real injected `ng`,
  * never `makeNg`), so this module imports no `@ng-org` package.

packages/client/src/ng-proxy.ts

@@ -48,7 +48,7 @@ export function makeNg(): Record<string, any> {
         };
       }
 
-      // TODO(anticipated API): inbox_post_link + capability operations — expose
+      // TODO(anticipated API): a sealed inbox deposit + capability operations — expose
       // here with their anticipated signatures, emulated for now.
 
       // Everything else: passthrough to the real SDK, unchanged.