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/migration-guide.md

@@ -99,7 +99,7 @@ The consumer application imports `@ng-org/web` / `@ng-org/orm` resolved to this
 via a build alias during the polyfill period. Removing the alias makes those imports
 resolve to the real SDK — the `ng`/`useShape`/`inbox` surface is SDK-identical, so
 no consumer code changes. The one non-SDK call — `configure(...)` /
-the POLYFILL-ERA block of `@ng-eventually/sdk` — is deleted. The lib itself disappears.
+the POLYFILL-ERA block of `@ng-eventually/polyfill` — is deleted. The lib itself disappears.
 
 ## The one break already taken: `declareConnections`