refactor: renommer client → sdk, et fusionner les deux portes en une

Deux mouvements de surface, aucun changement de comportement.

**`packages/client` → `packages/sdk`, `@ng-eventually/client` → `@ng-eventually/sdk`.**
« client » ne disait rien : ce paquet EST le SDK que l'application appelle, et c'est
tout ce qu'elle appelle. L'ancien nom reste comme mot-clé de recherche dans
`docs/source-layout-by-fate.md` et le tableau des paquets du README.

**Une seule entrée.** L'entrée `./polyfill` disparaît ; ses symboles applicatifs —
`configure`, `configureStoreRegistry`, `setCurrentUser`, `connectedUser` et leurs types
— vivent dans un bloc `POLYFILL-ERA` de `src/index.ts`.

Ce que la seconde porte portait mérite d'être nommé avant d'être retiré : *ce qu'on
importe de ce chemin est exactement ce qu'on supprimera à la migration*. Une seule
porte perd ce signal — rien à la ligne d'import ne distingue `configure`, qui part, de
`docs`, que le vrai SDK remplace sur place. Trois choses le portent désormais : le bloc
lui-même, l'inventaire d'exports de `docs/api-contract.md` (épinglé par
`test/vocabulary.test.ts`, donc il ne peut pas rancir en silence), et le contrôle de
vocabulaire sur les noms publiés.

**Six symboles quittent la surface au passage**, et la fusion est ce qui a rendu le
choix visible plutôt qu'hérité :

- `getConfig` / `getStoreRegistryDeps` — câblage interne, atteint par
  `shared-wallet/bootstrap` ;
- `resetConfig` / `resetStoreRegistry` / `resetCaps` — remises à zéro de test, atteintes
  par leur chemin interne, ce qui est leur raison d'être ;
- le `share` direct — `inbox.share` a toujours été la même fonction, et la publier deux
  fois brouillait la frontière qu'elle servait à marquer.

Corrections d'affirmations fausses trouvées en chemin : le contrat annonçait `isNuri` /
`hasReadCap` sur la porte SDK alors qu'ils ne sont plus exportés depuis le passage au
permissif en entrée (`NuriLike` validé à la porte) ; le README du paquet documentait
`capFor`, `shareCap`, `getCaps` et `publishRepoLink`, dont aucun n'existe ; et le README
de l'app d'exemple affirmait que la suite e2e la pilote, ce qui reste à faire.

179 tests unitaires, typecheck bibliothèque / exemple / harnais, e2e 42/42 contre le
broker en ligne — mesuré une fois après le renommage, une fois après la fusion.

docs/nextgraph-current-state.md

@@ -1,6 +1,6 @@
 # Current-state NextGraph — what the SDK/broker do and do NOT expose
 
-**Owner:** this library. `@ng-eventually/client` exists because the *current*
+**Owner:** this library. `@ng-eventually/sdk` exists because the *current*
 NextGraph JS SDK is immature. This file is the authoritative reference on what
 today's SDK/broker actually give us — the ground truth every polyfill in this
 lib compensates for. Read [`simulation.md`](./simulation.md) for how we emulate
@@ -323,7 +323,7 @@ has both**:
 - **Subscribable with a sync BARRIER.** `doc_subscribe(nuri)` delivers `TabInfo` then
   an initial **`State`** (`verifier.rs:470`/`:476`); that first `State` is the sync
   barrier — **after it, presence is guaranteed and absence is definitive** (pinned
-  empirically by CONTRACT 3 in `packages/client/e2e/`). But this barrier exists only
+  empirically by CONTRACT 3 in `packages/sdk/e2e/`). But this barrier exists only
   for a repo `doc_subscribe` can open, i.e. a `did:ng:o:<RepoID>` repo. A **store-root
   has no first-`State` barrier**: an anchored read on it can return 0 rows during
   sync-lag with no signal distinguishing "still syncing" from "genuinely empty".
@@ -747,7 +747,7 @@ chain never runs and consumers keep a stale value until the next connection
 delivers a fresh initial `State`. REMOTE commits DO push correctly (verified:
 cross-browser reactive update works). Verdict pending a live instrumented run.
 Full write-up (suspect link, instrumentation, planned polyfill-side fix):
-[`../packages/client/docs/sdk-reference.md`](../packages/client/docs/sdk-reference.md)
+[`../packages/sdk/docs/sdk-reference.md`](../packages/sdk/docs/sdk-reference.md)
 § *Current emulation status*.
 
 ### Cold-start anchored read returns 0 rows instead of an error — symptom VERIFIED, mechanism INFERRED, healed polyfill-side
@@ -756,7 +756,7 @@ On a FRESH session over the SAME persistent wallet (reconnect, new page, re-logi
 anchored `sparql_query` against a document written in an earlier session comes back with
 **0 rows and no error** — persisted documents read as empty. Observed on every anchored
 reader of the polyfill and healed identically in each (`ensureRepoOpen` before the read,
-`packages/client/src/emulated-verifier/open-repo.ts`): the user's own documents,
+`packages/sdk/src/emulated-verifier/open-repo.ts`): the user's own documents,
 the user's store (`shared-wallet/account-registry.ts` `readUserStore`), the by-need doc batch
 (`surface/read-model.ts` `readUnion`), and the store-root pointer read (`shared-wallet/account-registry.ts`
 `resolvePointer`). The heal is `doc_subscribe(nuri)` → await the first `State` (the sync
@@ -792,7 +792,7 @@ is a single account subject carrying MULTIPLE values for one scope predicate (ob
 five `shim:docPublic`), after which a writer and a later reader can resolve DIFFERENT
 scope docs and the reader's anchored read returns 0.
 
-Two polyfill-side guards, both in `packages/client/src/shared-wallet/account-registry.ts`: `ensureInFlight`
+Two polyfill-side guards, both in `packages/sdk/src/shared-wallet/account-registry.ts`: `ensureInFlight`
 (a bounded promise map keyed by account, so concurrent `ensureAccount` calls share ONE
 resolve-or-provision) prevents new forks; `canonicalDoc` (pick the lexicographically
 smallest NURI among all distinct values for a scope predicate — NURIs are