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. »

docs/simulation.md

@@ -11,7 +11,7 @@
 > file for *how* each emulation works; read those two for *what is fake* and *what
 > replaces it*.
 
-The consumer application writes against `@ng-eventually/sdk` as if NextGraph
+The consumer application writes against `@ng-eventually/polyfill` as if NextGraph
 already shipped per-entity documents in public/protected/private stores, capabilities
 and inboxes. It hasn't (see [`nextgraph-current-state.md`](./nextgraph-current-state.md)).
 This file is the lib's own engineering doctrine on how it fabricates that mature
@@ -187,7 +187,7 @@ virtual/physical distinction dissolves (see [`migration-guide.md`](./migration-g
 ### SDK-shaped scope resolvers — the consumer application holds no store-id
 
 The consumer application must never construct a `did:ng:${store_id}` NURI itself:
-physical placement is the lib's job (the whole point of the SDK boundary). Two
+physical placement is the lib's job (the whole point of the polyfill boundary). Two
 resolvers turn a logical scope into an opaque graph NURI without exposing any
 store-id:
 
@@ -452,7 +452,7 @@ the target's behaviour.
 The old item-level application-visibility filter (the since-deleted `isolation.ts`
 `applyIsolation`, a `Set`-of-records filter keyed on owner+scope) is retired
 from the consumer path: the application carries no access logic — it declares its
-identity and shares caps, and trusts the SDK. Its matrix functions are
+identity and shares caps, and trusts the polyfill. Its matrix functions are
 dead scaffolding kept for reference and removed at migration. There is no longer a
 second, coexisting app-layer filter to reconcile — the single axis is the
 per-document cap, exactly as in the target.
@@ -639,5 +639,5 @@ document trust root):
   (`did:ng:...`): validates and throws on IRI-breaking chars rather than emitting
   a malformed/injected query.
 
-These are re-exported from `@ng-eventually/sdk` so the consumer application
+These are re-exported from `@ng-eventually/polyfill` so the consumer application
 reuses the same escaping when it builds SPARQL.