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.

packages/sdk/src/surface/placement.ts

@@ -0,0 +1,55 @@
+/**
+ * The app-facing slice of `store-registry` — and the reason it exists as a file.
+ *
+ * `store-registry.ts` holds two things that must not be exported together: the
+ * placement/addressing calls a consumer application legitimately makes, and the
+ * shim machinery that makes virtual users work at all (account resolution, the
+ * durable cap registers, the inbox-ownership predicate, cache resets). Until now
+ * `index.ts` did `export * as storeRegistry from "../shared-wallet/account-registry"` and shipped
+ * both, so an application could reach `ensureAccount`, `addLink` or
+ * `resetRegistryCache` from the SDK-identical entry — machinery it must never call,
+ * on the entry whose whole promise is "this survives migration unchanged".
+ *
+ * What is re-exported here is only what an application needs to do its own work,
+ * and each has a target-SDK counterpart (see `docs/api-contract.md`). Everything
+ * else stays reachable at `./store-registry` for the library's own modules, the
+ * unit tests and the e2e harness — an internal path, not a published one.
+ *
+ * At migration this file disappears: placement becomes the user's real per-scope
+ * stores and the calls below become native SDK ones.
+ *
+ * **No inbox ADDRESS is published here**, deliberately (`userInbox`,
+ * `documentInboxAddress`, removed 2026-08-05). An application deposits with
+ * `inbox.postToDocument(doc, …)`, shares with `inbox.share(doc, toUser)` and reads
+ * its own with `inbox.readForDocument(doc)` — always naming a document or a person,
+ * never an address. Upstream an address is resolved from a profile and never handled by
+ * a caller, so exposing one taught a step that has to be unlearned. The example
+ * application is the check: it must never name an inbox.
+ */
+
+export {
+  /** Create a document for ONE entity in `scope`, and record it in that scope's store. */
+  createEntityDoc,
+  /** The entity documents this user owns in `scope` — with their caps recovered. */
+  listMyEntityDocs,
+  /** The NURI to use as a READ scope for `scope` (what `useShape` is pointed at). */
+  resolveScopeGraph,
+  /** The NURI where GROUPED entities of `scope` are written (no per-entity document). */
+  resolveWriteGraph,
+  /** Open an inbox on a document you OWN, so others can deposit into it. */
+  /** WHERE to deposit for a document — readable by any holder of it. `undefined` if none. */
+} from "../shared-wallet/account-registry";
+
+export { openDocumentInbox } from "../emulated-verifier/branch-registers";
+
+// No `linkTo` here, and its absence is deliberate (it existed 2026-08-06, one day).
+//
+// It returned a document's KEY where a caller would ask for its reference, which turns
+// the access rule from "whoever has the reference AND the key reads" into "whoever has
+// the reference reads" — see `docs/readcap-and-nuri-model.md` § 0. That is not a leak of
+// hygiene, it is the rule changing: a document one circulates would grant everything it
+// MENTIONS, and confidentiality could no longer be composed inside a shared document.
+//
+// An application names a document with the reference it already has (every call here
+// returns bare ones), and grants access with `inbox.share(doc, toUser)`. What travels
+// with a key in it is a deliberate act, not the result of asking for a link.