fix: mon correctif sur createEntityDoc était faux dans les deux sens

Second tour adverse sur le lot C. Six trouvailles, dont trois sur ce que je venais de
livrer.

**Le correctif de `createEntityDoc` reproduisait le défaut qu'il annonçait avoir fermé.**
Il levait sur la PREMIÈRE écriture de registre en échec. Or :

- lever sur le listing sautait l'écriture de la clé — détruisant le chemin de
  récupération que le commentaire d'à côté décrit explicitement (« la clé doit rester
  récupérable même si le listing a échoué »), et laissant le document orphelin ;
- lever sur la clé laissait le document LISTÉ sans clé — précisément l'état « se lit vide
  pour toujours » que je prétendais empêcher, en pire, puisque l'appelant n'a même plus
  sa référence.

Les deux écritures sont désormais tentées, ce qui atterrit reste, et l'échec est rapporté
après en nommant la moitié manquante.

**Le refus de `share` reposait sur une valeur qui confond absence et ignorance.**
`resolveAccount` avale toute erreur de lecture et rend `null`, si bien qu'un incident
réseau faisait répondre « personne ne s'est connecté sous ce nom » à propos de quelqu'un
qui existe. `lookupAccount` propage désormais l'erreur ; `resolveAccount` reste la forme
tolérante que tous les autres appelants veulent.

**J'avais livré ce comportement sans un seul test.** `test/app-surface.test.ts` en ajoute
huit, tous sur ce qu'un APPELANT voit : `ensureIdentity` rend l'identité, un appel de
placement avant connexion nomme l'erreur, le placement agit comme l'utilisateur connecté,
`share` refuse un nom inventé mais laisse remonter une panne, et une création à moitié
écrite échoue en disant quelle moitié — dont le cas « le listing a échoué, la clé est
quand même là ».

En écrivant ces tests j'ai refait dans leur faux la faute que cette revue a corrigée
ailleurs : ignorer le sujet dans la requête de compte, ce qui rendait le dossier d'un
autre utilisateur. Deux des huit échouaient pour cette raison, sans rapport avec le code.

**Et la documentation contredisait le code livré dans le même commit** : le README
enseignait encore `createEntityDoc(me, "protected")` — en JS la portée devient `"alice"` —
et le contrat déclarait `Nuri` là où le code et la feuille disent `NuriLike`.

197 tests unitaires, e2e 40/40 et applicatif 12/12.

packages/sdk/src/shared-wallet/account-registry.ts

@@ -575,7 +575,16 @@ async function resolveShimDoc(): Promise<Nuri> {
  * Cached per account (in `accountCache`); a hit skips the query entirely, so
  * repeated resolves of the same account are free. `resetRegistryCache` clears it.
  */
-export async function resolveAccount(id: string): Promise<VirtualUserRecord | null> {
+/**
+ * Does this account exist? **Propagates** a read failure instead of turning it into
+ * "no such account".
+ *
+ * `resolveAccount` below is tolerant by design — most callers want "carry on without a
+ * record". But a caller that REFUSES on absence needs the two apart: telling a user
+ * "nobody has signed in as bob" because one query timed out is a lie, and it made
+ * `inbox.share` reject a recipient who exists (found adversarially, 2026-08-10).
+ */
+export async function lookupAccount(id: string): Promise<VirtualUserRecord | null> {
   const key = accountKey(id);
   const cached = accountCache.get(key);
   if (cached) return cached;
@@ -611,6 +620,20 @@ export async function resolveAccount(id: string): Promise<VirtualUserRecord | nu
     return record;
   } catch (error) {
     console.error(accessLogPrefix() + " resolveAccount failed:", error);
+    throw error;
+  }
+}
+
+/**
+ * The account, or `null` when there is none — and `null` too when the read failed. The
+ * tolerant form every internal caller uses: none of them can act on the difference, and
+ * connecting must not break because a query did not come back. Use {@link lookupAccount}
+ * where absence is a REASON TO REFUSE.
+ */
+export async function resolveAccount(id: string): Promise<VirtualUserRecord | null> {
+  try {
+    return await lookupAccount(id);
+  } catch {
     return null;
   }
 }
@@ -983,41 +1006,36 @@ export async function createEntityDoc(id: string, scope: Scope): Promise<Nuri> {
   const indexDoc = storeOf(record, scope);
   const entityNuri = await createDoc();
   const s = await session();
+  const cap = mintCap(entityNuri);
+  // TWO writes, both attempted, and the failure reported only after. They are separate
+  // because upstream they are two commits on two branches — `ldp:contains` on the store's
+  // Main branch and `AddRepo { read_cap }` on its Store branch
+  // (`engine/verifier/src/request_processor.rs:697-710`) — and because either is worth
+  // having without the other: the cap alone lets the creator re-open its document, the
+  // listing alone makes it findable.
+  //
+  // A first attempt at surfacing the failure (2026-08-07) threw on the FIRST one, and an
+  // adversarial pass showed it was wrong in both directions: throwing on the listing
+  // skipped the cap write, orphaning the document entirely — destroying the very recovery
+  // the comment above describes — and throwing on the cap left the document LISTED with
+  // no key, which is precisely the "reads empty forever" state it claimed to prevent.
+  // Attempt both, keep what lands, and say exactly what state the document is in.
+  const failures: string[] = [];
   try {
     await registerUpdate(
       s.sessionId,
       // NO explicit `GRAPH <…>` wrapper: write the anchored DEFAULT graph (the
-      // `indexDoc` anchor scopes it) — the CANONICAL, always-safe shape the
-      // anchored default-graph read queries (readUserStore below, same as
-      // read-model.ts). Not a round-trip necessity on the current broker: the e2e
-      // harness (`packages/sdk/e2e/`) verified an anchored `GRAPH <plainNuri>`
-      // write ALSO round-trips here (same repo graph, no phantom graph); no-GRAPH
-      // is kept as a simplicity/safety convention. entityNuri is a NURI stored as
-      // a literal → escapeLiteral.
+      // `indexDoc` anchor scopes it) — the CANONICAL, always-safe shape the anchored
+      // default-graph read queries (readUserStore below, same as read-model.ts).
+      // entityNuri is a NURI stored as a literal → escapeLiteral.
       `INSERT DATA { <${MAIN_BRANCH_SUBJECT}> <${P.contains}> "${escapeLiteral(entityNuri)}" }`,
       indexDoc,
       "createEntityDoc",
     );
   } catch (error) {
-    // Not swallowed: a document absent from its store's listing is not a document. The
-    // next session's `listMyEntityDocs` omits it and `readUnion` returns nothing for it,
-    // so the caller has written content into a NURI that will read empty forever —
-    // silently. Upstream `doc_create` propagates its own commit failures
-    // (`engine/verifier/src/request_processor.rs:698,714`).
     console.error(accessLogPrefix() + " createEntityDoc index append failed:", error);
-    throw new Error(
-      "[ng-eventually] createEntityDoc: the document was created but could not be recorded " +
-        `in its store, so it would be lost to the next session: ${String(error)}`,
-    );
+    failures.push(`it is not listed in its store (${String(error)})`);
   }
-  // The second write: `AddRepo { read_cap }` on the Store branch. A separate
-  // statement, not a second triple in the one above, because upstream these are two
-  // commits on two branches — and because the cap must be recoverable even if the
-  // listing write failed.
-  //
-  // One literal suffices: a ReadCap CARRIES its document (`targetOf`), so storing the
-  // cap stores the pair.
-  const cap = mintCap(entityNuri);
   try {
     await registerUpdate(
       s.sessionId,
@@ -1026,12 +1044,16 @@ export async function createEntityDoc(id: string, scope: Scope): Promise<Nuri> {
       "createEntityDoc:addRepo",
     );
   } catch (error) {
-    // Same reasoning as the listing above: without its cap on the Store branch the
-    // creator cannot re-open its own document on a later session.
     console.error(accessLogPrefix() + " createEntityDoc cap append failed:", error);
+    failures.push(`its key is not recorded (${String(error)})`);
+  }
+  if (failures.length > 0) {
+    // The document EXISTS on the broker; what failed is the bookkeeping that makes it
+    // findable and re-openable. Returning its NURI would hand back a reference that reads
+    // empty on the next session, silently — so the caller is told instead.
     throw new Error(
-      "[ng-eventually] createEntityDoc: the document was created but its key could not be " +
-        `recorded, so its own creator would lose it: ${String(error)}`,
+      `[ng-eventually] createEntityDoc: the document ${entityNuri} was created but ` +
+        `${failures.join(", and ")}. It will not survive this session as it stands.`,
     );
   }
   // …and the creator holds THAT cap for this session.

packages/sdk/src/surface/inbox.ts

@@ -32,7 +32,7 @@ import { subscribeDoc } from "./subscribe";
 import { ensureRepoOpen } from "../emulated-verifier/open-repo";
 import { getCaps, getCurrentUser, getStoreRegistryDeps } from "../shared-wallet/bootstrap";
 import { addLink, documentInboxAddress, isOwnInbox } from "../emulated-verifier/branch-registers";
-import { userInbox, isKnownInbox, resolveAccount } from "../shared-wallet/account-registry";
+import { userInbox, isKnownInbox, lookupAccount } from "../shared-wallet/account-registry";
 import { escapeLiteral } from "./sparql";
 import { hasReadCap, toNuri } from "../model/nuri";
 import {
@@ -348,7 +348,12 @@ export async function share(doc: NuriLike, toUser: string): Promise<void> {
   // PUBKEY (`InboxMsg::new`, `engine/net/src/types.rs:4299`) that reached you through an
   // inbound `ContactDetails` — someone has to have reached you first. Refusing is the
   // faithful behaviour; provisioning was the invention.
-  if ((await resolveAccount(toUser)) === null) {
+  //
+  // `lookupAccount`, not `resolveAccount`: the tolerant form answers `null` for a read
+  // that FAILED as well as for one that found nothing, so it would have told a user
+  // "nobody has signed in as bob" because a query timed out. A refusal must not be
+  // built on a value that conflates absence with ignorance.
+  if ((await lookupAccount(toUser)) === null) {
     throw new Error(
       `[ng-eventually] inbox.share: no such recipient — nobody has signed in as ` +
         `${JSON.stringify(toUser)}. Sharing does not create the person you share with.`,