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!()`.

docs/simulation.md

@@ -464,7 +464,7 @@ fork the broker ([`fork-inbox-fallback.md`](./fork-inbox-fallback.md)), the lib
 emulates the inbox on the shared wallet:
 
 - **Target vs polyfill.** In the target, `post` seals a reference into the owner's
-  native inbox (`inbox_post_link(...)`, a proposed/future API) and the recipient's
+  native inbox — through a JS call that **does not exist and is not announced** — and the recipient's
   own verifier unseals each queued message and applies it inline when it processes
   its inbox — there is no separate curator or materialization process. Here,
   everything is readable, so the lib emulates the read side in-lib.
@@ -507,9 +507,10 @@ At migration this guard disappears into cryptography: an inbox is sealed to its
 owner's key.
 
 The module knows no domain — the consumer application supplies the inbox document
-NURI and interprets `payload`. At migration `post` becomes the native
-`inbox_post_link` (proposed/future) and the read side is served by the recipient's
-own verifier unsealing queued messages inline.
+NURI and interprets `payload`. At migration `post` becomes the native sealed
+deposit — **whose JS name and signature are not known**, since none is exposed or
+announced — and the read side is served by the recipient's own verifier unsealing
+queued messages inline.
 The inbox + watcher is the one deposit/read mechanism a consumer reuses for its own
 purposes — a registration/deposit, a cap delivery (`shareCap`), a link handed to
 someone — same `post` API, same watcher.