fix: trois chemins vers une inbox en double, et la lecture qui manquait

Une application a rapporté quatre appels simultanés sur un même document
enregistrant trois inboxes. Le contrat garantissait l'inverse. En cherchant, on
en a trouvé DEUX autres, indépendantes, qui produisent le même dégât durable :
le propriétaire surveille une inbox pendant que les dépôts arrivent dans une
autre.

La concurrence. openDocumentInbox ne partageait rien avec userInbox — module
différent, registre propre, aucune coalescence. Reproduit pire que rapporté :
quatre appels donnaient QUATRE inboxes. Une carte en vol par (détenteur,
document), et le corps déplacé pour que l'invariant soit porté par la
composition plutôt que par la position d'une vérification.

La limite est nommée plutôt que cachée : deux onglets ne partagent aucune carte,
chacun lit, chacun ne trouve rien, chacun frappe. Ce n'est pas réparable ici —
une branche est en ajout seul, et ça ne se réconcilie pas après coup, le
propriétaire lisant sa branche User quand un déposant lit l'adresse publiée du
document. Le contrat porte donc une garantie positive ET une non-garantie.

La page froide. readInboxCapPairs était le seul lecteur de store sans barrière,
correct uniquement parce qu'une autre fonction s'exécutait avant lui à la
connexion. Une dépendance d'ordre, pas une garantie portée par la lecture : sur
une page froide il lisait le store privé non synchronisé, répondait « aucune
inbox » et en frappait une seconde. Un seul appel, aucune concurrence. La
barrière est désormais dans la lecture, et elle ne coûte rien aux chemins
connectés, la connexion ayant déjà ouvert les trois stores.

Et la lecture qui manquait. readSynced donnait la garantie, readForDocument
l'adressage, pas leur intersection — si bien que matérialiser des dépôts
obligeait une application à résoudre une adresse d'inbox elle-même, ce que le
contrat lui interdit explicitement. inbox.readSyncedForDocument la lui épargne.
Elle traverse deux dépôts, l'adresse vivant sur l'en-tête du document et les
dépôts sur l'inbox — franchir la barrière sur la seule inbox ne réparait rien.

Au passage, le compteur d'identifiants de la doublure était par page : une page
rechargée refrappait le même identifiant PAR-DESSUS une inbox existante,
aliasant deux dépôts en silence. Il est monotone.

packages/polyfill/src/surface/inbox.ts

@@ -429,18 +429,39 @@ export async function share(doc: NuriLike, toUser: string): Promise<void> {
   await post(await userInbox(toUser, "protected"), { payload: { kind: LINK_KIND, cap } });
 }
 
+/**
+ * Turn a DOCUMENT into its deposits — the one place the document-addressed reads resolve
+ * an address, shared by both of them ({@link readForDocument} and
+ * {@link readSyncedForDocument}) so the two cannot come to disagree about what "this
+ * document has no inbox" means, exactly as {@link DEPOSITS_QUERY} is shared by the two
+ * readers of an inbox.
+ *
+ * Empty when the document has no inbox, which is a state and not an error. WHICH read of
+ * the inbox follows is the caller's, and it is the only thing the two differ by.
+ */
+async function depositsForDocument(
+  doc: Nuri,
+  readInbox: (inbox: Nuri) => Promise<Deposit[]>,
+): Promise<Deposit[]> {
+  const address = await documentInboxAddress(doc);
+  return address ? readInbox(address) : [];
+}
+
 /**
  * The messages left on a document YOU own — the read side of {@link postToDocument}.
  *
  * Named by the DOCUMENT, like the deposit side: an owner reading their own messages has
  * no more reason to handle an inbox address than a depositor does. Empty when the
  * document has no inbox, which is a state and not an error.
+ *
+ * The WARM read, like {@link read} it delegates to: it gates on no sync barrier, so on a
+ * fresh session over the same persistent wallet it can answer `[]` for a document that
+ * has deposits. {@link readSyncedForDocument} is the same address with that guarantee.
  */
 // @provenance inbox.readForDocument kind=divergent level=1 ref=engine/verifier/src/inbox_processor.rs:process_inbox — upstream an inbox is a queue the verifier consumes and APPLIES; this enumerates it instead, non-destructively
 export async function readForDocument(docLike: NuriLike): Promise<Deposit[]> {
   const doc = toNuri(docLike, "inbox.readForDocument");
-  const address = await documentInboxAddress(doc);
-  return address ? read(address) : [];
+  return depositsForDocument(doc, read);
 }
 
 // --- the read guard ------------------------------------------------------
@@ -598,6 +619,43 @@ export async function readSynced(targetInboxLike: NuriLike): Promise<Deposit[]>
   return read(targetInbox);
 }
 
+/**
+ * COLD, BARRIER-GATED read of the messages left on a document YOU own — the guarantee of
+ * {@link readSynced} on the address of {@link readForDocument}, and the one call that
+ * materializes deposits without an application ever holding an inbox address.
+ *
+ * ── Why the two do not compose by themselves ──────────────────────────────
+ * The document-addressed path crosses TWO repos, and a cold session (a reconnection, a new
+ * page) loses the answer at either one:
+ *
+ *   1. the DOCUMENT, whose Header branch carries the address (`documentInboxAddress`) —
+ *      unopened, that anchored read matches nothing, so the call concludes "no inbox" and
+ *      answers `[]` for a document whose inbox is full;
+ *   2. the INBOX, whose deposits are the answer — the cold-start {@link readSynced} exists
+ *      for.
+ *
+ * So this crosses the barrier on both, in that order: the document FIRST, because its
+ * address is what the second open is even for. Past it, an empty result MEANS empty, on
+ * the read an application actually makes.
+ *
+ * Gating only the inbox would fix nothing — that is `readSynced`, and reaching it needs an
+ * address. There is deliberately no published call that hands one out (see
+ * {@link postToDocument}), so composing the two was never the application's to do; the gap
+ * was reported by one that had resolved an address itself to get here.
+ */
+// @provenance inbox.readSyncedForDocument kind=divergent level=1 ref=engine/verifier/src/inbox_processor.rs:process_inbox — the same divergence as the two halves it composes: upstream an inbox is a queue the verifier consumes and applies, and the address is TOLD to you rather than read off a document. It adds no divergent ACT, it spares the caller one
+export async function readSyncedForDocument(docLike: NuriLike): Promise<Deposit[]> {
+  const doc = toNuri(docLike, "inbox.readSyncedForDocument");
+  // The cold, connection-triggered entry point, marked in the trace before the two
+  // BARRIER lines (open-repo.ts) it is about to produce — the document's, then its
+  // inbox's. A live session shows the whole document-addressed materialization together.
+  logStage("READSYNCEDFORDOCUMENT " + shortNuri(doc) + " (cold, barrier-gated)");
+  // The DOCUMENT, before the address is asked for. An unsynced document does not answer
+  // "this has no inbox" — it answers nothing, and the two are the same value here.
+  await ensureRepoOpen(doc);
+  return depositsForDocument(doc, readSynced);
+}
+
 /**
  * PROCESS an inbox: read it, and **apply** what it contains.
  *