fix(inbox): une inbox appartient à un document, jamais à plusieurs

Retour sur l'adresse par défaut livrée en 8a382f2, qui faisait pointer tout
document vers l'inbox de son propriétaire. C'était acheter le coût au prix de
la forme — le mauvais arbitrage pour cette bibliothèque.

Vérifié en amont : le verifier route un message entrant par
`inboxes: PubKey → RepoId` (`engine/verifier/src/verifier.rs:1677,1928`) et le
déchiffre avec la moitié privée de CE repo. Et `InboxMsgBody`
(`engine/net/src/types.rs:4265`) ne porte aucun document cible — il n'en a pas
besoin : l'adresse EST l'identification. Une inbox appartient donc à exactement
un repo, et faire tenir plusieurs documents derrière une inbox émule une
relation que le modèle ne peut pas exprimer.

Conséquences :

- `createEntityDoc` ne publie plus rien. Un document neuf n'a pas d'inbox et
  `documentInboxAddress` rend `undefined`.
- Une inbox s'ouvre par `openDocumentInbox(doc)`, sur décision du propriétaire.
  C'est aussi ce qui règle le coût sans toucher à la forme : seuls les
  documents destinés à RECEVOIR en paient une — l'app le sait, la bibliothèque
  non.
- `inbox.postToDocument(doc, { payload })` : l'app nomme le DOCUMENT, jamais une
  inbox. Lève quand le document n'en a pas, au lieu de rendre la main
  silencieusement — un dépôt qui disparaît sans erreur est exactement le bug que
  ce chemin traînait.
- Pas de champ « document cible » sur un dépôt. Ce serait une invention que les
  apps devraient désapprendre à la migration.

README, principe de conception : les deux moitiés sont contraignantes, et c'est
la seconde qu'on brade. La surface doit être au plus près du futur SDK, mais
l'IMPLÉMENTATION aussi doit être au plus près de ce que NextGraph prévoit, sans
exception. Ce qui est connu vaut spécification. La pression à dévier ne se
présente jamais comme une déviation : elle arrive comme un coût, une latence,
une gêne d'ergonomie — bien réels. Deux cas déjà rencontrés sont consignés, avec
le signal commun : un choix qui ferait apprendre au consommateur quelque chose
qu'il devra DÉSAPPRENDRE.

157 tests unitaires, e2e 40/40 contre le broker en ligne.

packages/client/test/cross-user-access.test.ts

@@ -38,7 +38,7 @@ import {
   shareCap,
   connectedUser,
 } from "../src/polyfill";
-import { post, read as readInbox } from "../src/inbox";
+import { post, postToDocument, read as readInbox } from "../src/inbox";
 import { readUnion } from "../src/read-model";
 import { sparqlUpdate } from "../src/docs";
 import type { Nuri } from "../src/types";
@@ -444,36 +444,38 @@ test("opening an inbox on someone else's document is refused, not silently forke
   expect(await documentInboxAddress(doc)).toBe(aliceInbox);
 });
 
-test("a document is addressable from creation — its owner's inbox, no second document", async () => {
+test("a fresh document has NO inbox — one belongs to one document, and only its owner opens it", async () => {
   inject();
   setCurrentUser("alice");
-  const aliceInbox = await walletInbox("alice");
   const doc = await createEntityDoc("alice", "public");
   const link = capFor(doc)!;
 
-  // No `openDocumentInbox` anywhere: a depositor must not have to wait for the owner
-  // to open one. This is the window the consumer's central act falls into — signing up
-  // to someone else's document, before that owner ever touched an inbox.
+  // Not "the owner's inbox by default": upstream an inbox belongs to exactly ONE repo
+  // (the verifier routes by `inboxes: PubKey → RepoId`), so pointing several documents
+  // at one inbox is a relation the model cannot express.
   setCurrentUser("bob");
   getCaps().learn(link);
-  expect(await documentInboxAddress(doc)).toBe(aliceInbox);
+  expect(await documentInboxAddress(doc)).toBeUndefined();
+  // …and depositing THROWS rather than vanishing — a lost deposit is the bug this
+  // whole path exists to close.
+  await expect(postToDocument(doc, { payload: { x: 1 } })).rejects.toThrow(/has no inbox/i);
 });
 
-test("opening a dedicated inbox REPLACES the published address — it never accumulates", async () => {
+test("opening an inbox publishes ONE address, and re-opening does not accumulate", async () => {
   inject();
   setCurrentUser("alice");
-  const aliceInbox = await walletInbox("alice");
   const doc = await createEntityDoc("alice", "public");
-  expect(await documentInboxAddress(doc)).toBe(aliceInbox); // the general one, first
   const dedicated = await openDocumentInbox(doc);
-  expect(dedicated).not.toBe(aliceInbox);
+  expect(await openDocumentInbox(doc)).toBe(dedicated); // idempotent
 
-  // A depositor resolving now must reach the DEDICATED one, and only it: a stale
-  // address left beside the new one is a deposit written where nobody reads.
   const link = capFor(doc)!;
   setCurrentUser("bob");
   getCaps().learn(link);
   expect(await documentInboxAddress(doc)).toBe(dedicated);
+  // The deposit reaches the owner, addressed by the document alone.
+  await postToDocument(doc, { payload: { signingUp: true } });
+  setCurrentUser("alice");
+  expect((await readInbox(dedicated)).map((d) => d.payload)).toEqual([{ signingUp: true }]);
 });
 
 test("the inbox address is machinery: it never surfaces as the document's data", async () => {