feat: le polyfill possède la session et la normalisation des identités

Pour démarrer, une application devait écrire une promesse autour du callback
d'init(), attraper l'événement loggedin, puis fournir un thunk getSession qui
dépiaute session_id et les trois identifiants de store dans notre forme. Plus un
normalizeId. C'est précisément la plomberie que ce paquet existe pour absorber :
chaque application la réécrirait à l'identique, et c'est elle qui a produit deux
défauts aujourd'hui — un blocage et un partage cassé en silence.

En amont, une session est RENDUE ; une application n'en assemble jamais une à
partir de champs bruts. Et les identités virtuelles sont une invention du
polyfill, donc leur normalisation lui appartient.

Le wrapper init() enveloppe désormais le callback de l'appelant : il capture
l'événement, en dérive la session, puis appelle le callback avec le même
événement. Le paquet n'appelle jamais init de sa propre initiative — il
l'enveloppe. Sans callback, il capture quand même.

getSession et normalizeId quittent la surface publiée. Le chemin d'injection
reste pour les harnais, mais inatteignable depuis l'entrée : vérifié par un
import à l'exécution et par un configure() refusé à la compilation.

Défaut trouvé et corrigé en route : le broker envoie session_id en NOMBRE, et le
convertir en chaîne faisait refuser tous les appels par le binding wasm. La
valeur ne fait que transiter, elle est relayée telle quelle. Reste que toute la
chaîne la type string — inexactitude antérieure à ce commit, à traiter à part.

Une application écrit maintenant : configure({ ng, useShape, init, sharedWallet }).

packages/polyfill/test/sign-in-connects.test.ts

@@ -9,23 +9,39 @@
  * ── The mechanism, so a future reader can judge a change against it ────────
  * Settling the identity called `setCurrentUser`, which FIRES the connection work. Firing is
  * not awaiting, but it is still running: the work's first act is `resolveAccount`, which
- * awaits the consumer's `getSession` thunk. Settling happens before `init()` has been
- * delegated to — and the reference application builds its `sessionReady` promise AROUND
- * that very `init()` call, so at that instant the promise it would wait on does not exist.
- * The thunk could not answer. It threw, `resolveAccount` answered null, and the run
- * abandoned before restoring a single capability — after registering itself as the
- * connection in flight. The `connectedUser()` that `ensureIdentity()` awaits then JOINED
- * that abandoned run instead of doing the work, and resolved having done nothing. The
- * application rendered, and Bob held no key to a note that had been shared with him.
+ * awaits the session. Settling happens before `init()` has been delegated to — and the
+ * reference application built its `sessionReady` promise AROUND that very `init()` call, so
+ * at that instant the promise it would wait on did not exist. The session could not be
+ * answered. It threw, `resolveAccount` answered null, and the run abandoned before
+ * restoring a single capability — after registering itself as the connection in flight. The
+ * `connectedUser()` that `ensureIdentity()` awaits then JOINED that abandoned run instead of
+ * doing the work, and resolved having done nothing. The application rendered, and Bob held
+ * no key to a note that had been shared with him.
  *
  * So what is pinned is not "the calls happen in this order" — a regression would still call
- * them in order. It is what each half TOUCHES: settling must not call the session thunk at
- * all, and signing in must not come back until the thunk has actually answered.
+ * them in order. It is what each half TOUCHES: settling must not reach for the session at
+ * all, and signing in must not come back until the session has actually answered.
+ *
+ * ── What moved on 2026-08-12, and what it does not excuse ─────────────────
+ * The session is no longer the application's to supply: the package captures it from
+ * `init()`'s callback and holds it (`shared-wallet/session.ts`), so the promise the
+ * connection work waits on is now the library's own. That closes the *shape* of the failure
+ * above — a holder that WAITS cannot throw, so a run can no longer abandon for want of an
+ * answer. It closes nothing about the ordering: the session still arrives only through
+ * `init()`, so a half that reached for it too early would still be waiting on something
+ * that does not exist yet. Both properties below are therefore still worth their assertion,
+ * and the fixture instruments the package's own holder rather than a consumer's thunk.
  */
 import { test, expect, afterEach } from "bun:test";
 import { configure, ensureIdentity } from "../src/index";
 import { init } from "../src/surface/lifecycle";
-import { resetConfig, resetStoreRegistry, setCurrentUser } from "../src/shared-wallet/bootstrap";
+import {
+  configureStoreRegistry,
+  resetConfig,
+  resetStoreRegistry,
+  setCurrentUser,
+} from "../src/shared-wallet/bootstrap";
+import { sharedWalletSession } from "../src/shared-wallet/session";
 import type { RegistrySession } from "../src/shared-wallet/account-registry";
 
 const APP = "https://app.example/";
@@ -73,39 +89,46 @@ afterEach(() => {
 
 /**
  * The reference application's bootstrap, in its real order (`examples/notebook/app.ts`):
- * `configure()` first, then `init()` called from INSIDE the executor that builds the very
- * promise the session thunk waits on.
+ * `configure()`, then `init()` — and nothing else, since the session stopped being
+ * something an application assembles.
  *
- * That shape is not a curiosity of this fixture, it is what the e2e serves: in the bundle,
- * `sessionReady` is a hoisted `var`, so while the executor runs it is still `undefined` and
- * the thunk has nothing to wait on. It therefore **refuses** rather than blocking — and an
- * application is entitled to refuse, since at that moment there is genuinely nothing to
- * return. A thunk that merely blocked would hide the whole defect, which is why the double
- * here refuses exactly as the application's does.
+ * The injected `init` produces the session the way the real one does: by calling the
+ * callback it was handed, with `{ status: "loggedin", session }` (`ngweb.js:124`). Before
+ * it is called, nothing in the system can make the session exist — which is the whole
+ * cycle these two tests measure.
  *
- * The injected `init` resolves the session, as the real one does through its callback:
- * before it is called, nothing in the system can make the session exist.
+ * The counters sit on the REGISTRY's route to the session, substituted through the internal
+ * wiring path. That is where the connection work actually asks, so it is where "was it
+ * reached, and did it answer" can be told apart. `refused` is kept though the package's
+ * holder cannot throw: a future change that put a refusing thunk back on this route is
+ * exactly the regression the file exists to catch, and a counter nobody kept would let it
+ * back in silently.
  */
 function bootTheApplication(identifier: string) {
-  /** What the consumer's thunk was asked, and what it was able to say. */
+  /** What the registry's route to the session was asked, and what it was able to say. */
   const thunk = { asked: 0, answered: 0, refused: 0 };
-  let session: RegistrySession | null = null;
-  // Deliberately assigned AFTER `init()` runs — see above. `undefined` until then.
-  let sessionReady: Promise<RegistrySession> | undefined;
-  let arrive!: (s: RegistrySession) => void;
 
   configure({
     ng: {} as never, // no store behind it: the assertions are about what is REACHED
     useShape: (() => {}) as never,
-    init: (..._args: unknown[]): Promise<string> => {
-      arrive({ sessionId: "s", privateStoreId: "did:ng:o:private" });
+    init: (...args: unknown[]): Promise<string> => {
+      const callback = args[0];
+      if (typeof callback === "function") {
+        void (callback as (e: unknown) => unknown)({
+          status: "loggedin",
+          session: { session_id: "s", private_store_id: "did:ng:o:private" },
+        });
+      }
       return Promise.resolve("delegated");
     },
+    sharedWallet: { fileUrl: "/w.ngw", password: "pw" },
+  });
+
+  configureStoreRegistry({
     getSession: async (): Promise<RegistrySession> => {
       thunk.asked += 1;
       try {
-        const s = session ?? (await sessionReady!);
-        const answer = { sessionId: s.sessionId, privateStoreId: s.privateStoreId };
+        const answer = await sharedWalletSession();
         thunk.answered += 1;
         return answer;
       } catch (refusal) {
@@ -114,26 +137,20 @@ function bootTheApplication(identifier: string) {
       }
     },
     normalizeId: (id: string) => id.trim().replace(/^@/, "").toLowerCase(),
-    sharedWallet: { fileUrl: "/w.ngw", password: "pw" },
   });
 
   inBrokerIframe(`${APP}?ng-id=${encodeURIComponent(identifier)}`);
 
-  let delegated!: Promise<unknown>;
-  sessionReady = new Promise<RegistrySession>((resolve) => {
-    arrive = resolve;
-    delegated = init(() => {}, true, []) as Promise<unknown>;
-  });
-  void sessionReady.then((s) => { session = s; });
+  const delegated = init(() => {}, true, []) as Promise<unknown>;
 
   return { thunk, delegated };
 }
 
-test("settling the identity never asks the application for a session", async () => {
+test("settling the identity never reaches for a session", async () => {
   // The session-free half, taken at its word. `init()` awaits settling and nothing else, so
-  // by the time it has delegated, the consumer's thunk must not have been called ONCE —
-  // not called-and-blocked, not called-and-refused, not called at all. Anything the gate
-  // reaches that ends up at `getSession` is outside the half it claims to be.
+  // by the time it has delegated, the session must not have been asked for ONCE — not
+  // asked-and-blocked, not asked-and-refused, not asked at all. Anything the gate reaches
+  // that ends up at the session is outside the half it claims to be.
   const app = bootTheApplication("bob");
 
   await app.delegated;
@@ -146,7 +163,7 @@ test("signing in does not come back until the connection work has reached a live
   // The consequence, from the application's side. `ensureIdentity()` promises that what was
   // shared with you is readable when it resolves; it can only keep that promise by having
   // restored and drained, and both begin by resolving the account — which needs the
-  // session. So a run that resolved without the thunk ever ANSWERING did no such work,
+  // session. So a run that resolved without the session ever ANSWERING did no such work,
   // whatever it reported. That is exactly the state Bob's page was in.
   const app = bootTheApplication("bob");
   await app.delegated;