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/src/shared-wallet/account-registry.ts

@@ -262,12 +262,13 @@ export interface RegistrySession {
 
 function normalize(id: string): string {
   const key = getStoreRegistryDeps().normalizeId(id);
-  // The reserved namespace's whole guarantee is that no user id can land in it, and
-  // that guarantee is NOT ours to make: `normalizeId` is injected by the consumer
-  // application, and the library's own default only trims — nothing stops a caller
-  // from passing an id that already starts with the sentinel. A collision here is not
-  // a cosmetic clash: a user would key onto an infrastructure account and read or
-  // write documents that are not theirs. So it is checked rather than assumed.
+  // The reserved namespace's whole guarantee is that no user id can land in it, and the
+  // rule that produces the key does not enforce it: the package's own `normalizeIdentityId`
+  // trims, strips a leading `@` and lowercases — nothing stops an id that already starts
+  // with the sentinel — and the internal wiring path lets a suite or the e2e harness
+  // substitute another rule entirely. A collision here is not a cosmetic clash: a user
+  // would key onto an infrastructure account and read or write documents that are not
+  // theirs. So it is checked rather than assumed.
   if (isReserved(key)) {
     throw new Error(
       "[ng-eventually] account-registry: `normalizeId` produced a key inside the " +