fix: ne pas re-provisionner un compte sur un read 0-lignes dû au lag de sync

Cause racine mesurée (broker réel, access-log) : à la première resolveAccount
d'une session, le record de compte tout juste persisté (ou d'une session
antérieure) peut lire 0 lignes à cause du LAG DE SYNC broker. ensureAccount
interprétait ce 0 comme « compte inexistant » et RE-PROVISIONNAIT un second jeu
de docs de scope (docPublic/docProtected forkés) → les lectures d'une session
tombaient sur un jeu, celles d'une autre (ou après drop de cache) sur l'autre
jeu vide → données « perdues » à la reconnexion.

Fix : `resolveAccountReliably` (store-registry.ts) — retry borné (ouverture du
repo d'ancre shim + backoff plafonné, défaut 8 tentatives / ≲8.5s) AVANT que
ensureAccount ne décide qu'un compte est neuf. Provisionne seulement si, après
le budget, la lecture rend toujours 0 (compte réellement neuf). Budget injecté
via StoreRegistryDeps.provisionRetry (polyfill.ts), ON en prod ; tests unitaires
à provisionRetry synchrone (attempts:1, fake sans lag). Idempotence de session
préservée par accountCache (hit court-circuite, déterministe).

Portée : corrige le déterminisme de provisioning. NE suffit PAS à réparer la
reconnexion (le read public à 0 same-session subsiste, cause distincte encore à
mesurer de façon déterministe — le lag broker rend les mesures non-reproductibles).
Complémentaire du commit open-repo précédent, pas redondant.

gate : tsc --noEmit propre ; bun test 91 pass ; auth @data (vide/distinctes) verts.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

packages/client/src/polyfill.ts

@@ -24,6 +24,20 @@ export interface StoreRegistryDeps {
   getSession: () => Promise<RegistrySession>;
   /** Normalize an identity id for shim keying. Default: trim (identity-ish). */
   normalizeId?: (id: string) => string;
+  /**
+   * ANTI-FORK budget for account resolution (polyfill-era). Before provisioning
+   * a "missing" account, the registry re-reads its shim record a bounded number
+   * of times with backoff, so a record merely lagging by broker sync (fresh
+   * session over a persistent wallet) is FOUND and REUSED instead of triggering
+   * a second set of scope docs (the account fork). See the note in
+   * store-registry.ts. Only if every attempt still reads 0 do we provision.
+   *
+   * Default (production): a real budget (~8 attempts / ≲8.5s). Set `attempts: 1`
+   * to disable the retry entirely — appropriate for a SYNCHRONOUS in-memory
+   * store (the unit fake `ng`) where a 0-row read is authoritative and the
+   * backoff would only add dead time; there is no sync lag to wait out there.
+   */
+  provisionRetry?: { attempts?: number; baseMs?: number; maxStepMs?: number };
 }
 
 export interface EventuallyConfig {
@@ -84,6 +98,13 @@ export function configureStoreRegistry(deps: StoreRegistryDeps): void {
   registryDeps = {
     getSession: deps.getSession,
     normalizeId: deps.normalizeId ?? ((id: string) => id.trim()),
+    // Production default: a real anti-fork budget. Consumers over a synchronous
+    // store pass `{ attempts: 1 }` to opt out (see StoreRegistryDeps).
+    provisionRetry: {
+      attempts: deps.provisionRetry?.attempts ?? 8,
+      baseMs: deps.provisionRetry?.baseMs ?? 300,
+      maxStepMs: deps.provisionRetry?.maxStepMs ?? 1500,
+    },
   };
 }