refactor: le paquet s'appelle polyfill, « SDK » désigne celui de NextGraph

Le nom @ng-eventually/sdk entrait en collision avec le SDK de NextGraph, dont
ce paquet est justement un polyfill. Impossible d'écrire « le SDK » sans lever
l'ambiguïté à chaque phrase — et le contrat publié, lu par une application,
était le pire endroit pour laisser traîner ça.

packages/sdk → packages/polyfill, @ng-eventually/sdk → @ng-eventually/polyfill,
contract_sdk-surface → contract_polyfill-surface, e2e/sdk-entry.ts →
e2e/polyfill-entry.ts, docs/sdk-reference.md → docs/polyfill-reference.md.

Les occurrences de « SDK » qui désignent celui de NextGraph restent intactes,
y compris les chemins dans nextgraph-rs (sdk/js/orm, sdk/js/web). Le tri s'est
fait occurrence par occurrence, pas par substitution.

Le contrat énonce désormais son identité en une phrase : « This package is a
polyfill of NextGraph's SDK. »

.project/concepts/app-contract/_debt.md

@@ -0,0 +1,14 @@
+# Doc-debt — app-contract
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## The broker redirect is stated as the application's obligation, and it is not
+
+**why** — `contract_polyfill-surface.md` lists, under `### Deployment requirements`, that the application must "be opened through the broker redirect". No such obligation belongs to the caller: the redirect is a step of the shared-wallet sign-in, which lives in this package (`access-gate.ts`, "the whole shared-wallet sign-in, moved out of consumer applications"). An application carrying it would have to know there is a broker, an iframe, and a redirect — three things the target SDK will never show it, and three things it would have to delete at migration.
+
+The clause was written from an absent implementation: nothing in `src/` navigates to the redirect today, and that gap was recorded as a division of roles. `rule_no-divergence-from-nextgraph` forbids exactly that inference.
+
+**files** — the clause is in the contract; the fix is in the package: `ensureIdentity()` triggers the redirect itself once the identity is settled and `?ng-id=` is written into the URL, and does nothing when already inside the iframe.
+
+**verify** — `contract_polyfill-surface.md` (`### Deployment requirements` keeps only the wallet file/password and the `ensureIdentity()` await), `knowledge_what-an-app-deletes-at-migration.md` (the redirect is one more thing that evaporates), `_overview.md` if the surface list changes.

.project/concepts/app-contract/_overview.md

@@ -1,19 +1,19 @@
 ---
 type: overview
-summary: What an application may rely on from @ng-eventually/sdk, and what it will have to delete
+summary: What an application may rely on from @ng-eventually/polyfill, and what it will have to delete
 triggers:
   keywords: [polyfill, sdk, surface, contract, publish, published, entry, export, migration, unlearn, consumer, app-facing]
   paths:
-    - "packages/sdk/src/index.ts"
-    - "packages/sdk/src/surface/**"
-    - "packages/sdk/README.md"
+    - "packages/polyfill/src/index.ts"
+    - "packages/polyfill/src/surface/**"
+    - "packages/polyfill/README.md"
     - "examples/notebook/**"
     - "docs/api-contract.md"
 vocabulary:
   - term: reference
     gloss: a NURI that names a document and grants nothing — what an application circulates
     not: [link, lien, share-link]
-    see: contract_sdk-surface
+    see: contract_polyfill-surface
   - term: ReadCap
     gloss: upstream's word for what opens a document — a reference carrying its secret
     not: [token, credential, permission]
@@ -29,10 +29,10 @@ This library exists so an application can be **written today against the NextGra
 
 The distinguishing question, asked at every choice — published signature as much as internal mechanism: **does the target do this?** If it does it differently, we do it their way, whatever that costs. *Would a caller have to unlearn it?* comes second, and measures how bad a divergence is — never whether one is allowed. See `rule_no-divergence-from-nextgraph`.
 
-This repo is the **provider** of `contract_sdk-surface`; consuming applications live in other repos and pull it. The per-symbol ruling, with an epistemic label on every target-side claim, stays here in `docs/api-contract.md` — that is maintainer material, not the engagement.
+This repo is the **provider** of `contract_polyfill-surface`; consuming applications live in other repos and pull it. The per-symbol ruling, with an epistemic label on every target-side claim, stays here in `docs/api-contract.md` — that is maintainer material, not the engagement.
 
 ## Read first
 
-- `contract_sdk-surface` — the engagement itself, written from the caller's point of view.
+- `contract_polyfill-surface` — the engagement itself, written from the caller's point of view.
 - `rule_no-divergence-from-nextgraph` — the test that decides what may be built at all.
 - `knowledge_what-an-app-deletes-at-migration` — the two fates a published symbol can have.

.project/concepts/app-contract/contract_polyfill-surface.md

@@ -1,12 +1,14 @@
 ---
 type: contract
-summary: The API @ng-eventually/sdk exposes to an application — signatures, guaranteed behaviour, and what it does not offer
+summary: The API @ng-eventually/polyfill exposes to an application — signatures, guaranteed behaviour, and what it does not offer
 ---
 
-# contract_sdk-surface — `@ng-eventually/sdk`
+# contract_polyfill-surface — `@ng-eventually/polyfill`
 
 ## Scope
 
+This package is a polyfill of NextGraph's SDK.
+
 This package covers placement (creating and listing an application's documents by scope), reading (a document's subjects, one-shot or reactive), sharing a document with a named user, and depositing into inboxes. It does not cover user management, display names, transport, or the operation of a deployment.
 
 ### Deployment requirements
@@ -19,7 +21,7 @@ An application using this package must:
 
 ## Surface
 
-Full typed shape: the package's `types` entry, `@ng-eventually/sdk`. A type is published only when a published signature uses it. The load-bearing signatures:
+Full typed shape: the package's `types` entry, `@ng-eventually/polyfill`. A type is published only when a published signature uses it. The load-bearing signatures:
 
 ```ts
 // ── bootstrap ────────────────────────────────────────────────────────────

.project/concepts/app-contract/knowledge_what-an-app-deletes-at-migration.md

@@ -7,7 +7,7 @@ summary: The two fates a published symbol can have, and why the deletion list is
 
 Every published symbol has exactly one of two fates, and knowing which is the whole point of this boundary.
 
-**Replaced in place.** The build alias resolving `@ng-eventually/sdk` is removed, the import resolves to the real SDK, and the application's code is unchanged. This is almost everything: `ng`, `useShape`, `watchShape`, `init`, `initNg`, `readUnion`, `subscribeDoc(s)`, `docs.*`, `inbox.*`, `storeRegistry.*`, and the types.
+**Replaced in place.** The build alias resolving `@ng-eventually/polyfill` is removed, the import resolves to the real SDK, and the application's code is unchanged. This is almost everything: `ng`, `useShape`, `watchShape`, `init`, `initNg`, `readUnion`, `subscribeDoc(s)`, `docs.*`, `inbox.*`, `storeRegistry.*`, and the types.
 
 **Deleted.** The symbol has no counterpart at any level of the target, exists only because one shared wallet hosts every user, and goes with its call site. Today that is `configure` and its config type.