refactor(api): le bootstrap redescend de quatre appels à un

L'objectif acté était deux appels spécifiques au polyfill, voire un. Il en publiait
quatre. Chacun des trois de trop était une raison que la BIBLIOTHÈQUE a, pas un besoin
qu'une application a :

- **`configureStoreRegistry`** existait parce qu'il y a deux internes à câbler — le SDK
  injecté d'un côté, la session de l'autre. Vu de l'appelant, les deux disent « voici ce
  qu'il te faut pour tourner ». Replié dans `configure`, qui prend désormais
  `getSession` / `normalizeId` / `pointerGuard`.
- **`setCurrentUser`** n'a plus lieu d'être publié depuis que le portail d'accès est
  passé dans le polyfill : c'est lui qui pose l'identité. Et une application qui nomme
  sa propre identité est exactement le geste qui inverse le modèle — il ne doit pas
  exister d'appel publié vers lequel se tourner. Le harnais e2e, lui, joue plusieurs
  identités sur une même page ; il y accède par le chemin interne, ce qu'un harnais a
  le droit de faire et une application non.
- **`connectedUser`** est maintenant attendu DANS `ensureIdentity`. Ce n'était pas une
  commodité : la suite applicative avait montré qu'une app devait l'attendre elle-même,
  sinon une note qu'on venait de lui partager se lisait comme illisible. J'avais traité
  le symptôme dans l'app d'exemple ; le défaut était côté bibliothèque. En amont, ouvrir
  la session EST la connexion — aucune application n'attend un second appel.

Reste donc `configure({ … })`, plus `await ensureIdentity()` dont le site d'appel
survit à la migration : une application attendra toujours une session avant de rendre.

Le test étendu hier a fait son travail : les deux contrôles de contrat sont passés au
rouge sur `configureStoreRegistry`, `connectedUser` et `StoreRegistryDeps` dès que la
surface a bougé.

180 tests unitaires, e2e 40/40 (3,4 min) et applicatif 10/10 (0,8 min).

docs/simulation.md

@@ -142,7 +142,7 @@ public/protected/private stores — on top of one shared wallet.
   `listMyEntityDocs(id, scope)` (its own account, bounded — no cross-account fan-out).
 - **Generic by construction.** The registry knows only the three native scopes,
   zero application entity kind. The consumer application maps its entities to a scope
-  and injects the session + identity-id normalization via `configureStoreRegistry({
+  and injects the session + identity-id normalization through `configure({
   getSession, normalizeId })` (`shared-wallet/bootstrap.ts`, published by the entry).
 
 The `store≠document` two axes materialize here directly: the registry moves along
@@ -238,7 +238,7 @@ store-id:
 Both resolve the native store ids from the injected session
 (`RegistrySession.protectedStoreId` / `publicStoreId`, alongside the existing
 `privateStoreId` anchor). The consumer application hands the whole session to the
-lib at the one injection point (`configureStoreRegistry({ getSession })`) — that is
+lib at the one injection point (`configure({ getSession })`) — that is
 wiring, not placement logic; everything else in the consumer application speaks only
 in scopes. If the session omits `protectedStoreId`, the non-private scopes fall back
 to the private store rather than emit a broken NURI.
@@ -361,7 +361,7 @@ another name.
 
 ### Sharing, publication, and the recipient
 
-- **`setCurrentUser(id)` (`shared-wallet/bootstrap.ts`)** — the SDK's "current identity" call.
+- **`setCurrentUser(id)` (`shared-wallet/bootstrap.ts`, INTERNAL since 2026-08-07 — `ensureIdentity` is what an application calls)** — the SDK's "current identity" call.
   It selects *whose* caps are consulted, lazily, so the delivered subset always
   reflects the identity in effect at read time.
 - **`inbox.share(doc, toUser)`** — the one sharing act the lib exposes. Recipients