feat!: useShapeQuery lit par la requete de forme du SDK

packages/polyfill/e2e/orm-live-entry.ts

@@ -1,20 +1,12 @@
 /**
- * The page for the LIVE ORM measurement — the one thing `e2e/polyfill-entry.ts` cannot do.
+ * The page for the LIVE ORM measurement - what `e2e/run.ts` still does not measure.
  *
- * That harness injects a hand-written Set-like into `configure({ useShape })`, because the
- * read filter is pure and does not need the real ORM to be exercised. What it therefore
- * never touches is the only hop that reaches the broker: `ng.orm_start_graph`, the streamed
- * method `OrmSubscription` opens and the one `bug_useshape-live-read-needs-a-newer-broker`
- * is about. So this page injects the REAL `@ng-org/orm` — nothing else about the bootstrap
- * differs — and the published `useShape` runs over a live subscription.
- *
- * ── The dependency, stated because it is not installed by default ──────────
- * `@ng-org/orm` is an OPTIONAL PEER of this package (`package.json`,
- * `peerDependenciesMeta`), so `bun install` does not fetch it and `bun.lock` records it
- * under `optionalPeers` with no resolution. This page is the only thing in the repository
- * that imports it: `e2e/run.ts` and its harness do not, so a checkout without it still
- * builds and runs the 42-check suite. Here the bundle simply will not build, and the
- * runner says so rather than reporting a broker verdict it did not measure.
+ * The 42-check harness injects the REAL `RdfOrmSubscription.getOrCreate` since
+ * `1.0.0-dev.6` (that is what `useShapeQuery` reads through), so a live ORM read is no
+ * longer unreachable from there. What stays here is the PUBLISHED `useShape` half: the
+ * bare `DeepSignalSet` an application gets from the ORM hook, and a `.delete()` on it
+ * reaching the document. That is a different surface from the snapshot `useShapeQuery`
+ * publishes, and it has no other measurement.
  *
  * ── What the framework adapter contributes, and why it is not here ─────────
  * Upstream's `useShape` is React's (`sdk/js/orm/src/frontendAdapters/react/useShape.ts`):
@@ -247,51 +239,6 @@ async function seededTripleCount(doc: Nuri, subject: string): Promise<number> {
     }
   },
 
-  /**
-   * CHARACTERISATION of the deployed broker's `orm_start_graph` ARITY.
-   *
-   * The failure the runner reports named a parameter - `config` - that the client of
-   * the day did not send. Two upstream arrangements could put one there, and they differ
-   * by POSITION:
-   *   - config LAST, after the callback (upstream 2026-04-12 to 2026-04-21) — an
-   *     unsupplied `config`, never a Function;
-   *   - config at index 4, BEFORE the callback: the 5-argument call of the client of
-   *     the day then lands its callback exactly there, which is what the error described.
-   *
-   * THE UPDATE ANSWERED THAT QUESTION. `@ng-org/web@0.1.2-alpha.14` declares six
-   * arguments with `config` at index 4 and routes the stream callback from index 5
-   * (`dist/ngweb.js`: `orm_start_graph: 5`), and `@ng-org/orm@0.1.2-alpha.21` sends six
-   * to match (`dist/connector/RdfOrmSubscription.js:159`). So the second arrangement was
-   * the right reading, and the ordinary `liveStart` path now exercises it.
-   *
-   * This is therefore kept as a FALLBACK, not as the live question: the runner only asks
-   * it when `liveStart` did not become ready, to say whether the engine still refuses on
-   * `config` when the client no longer can be blamed. It calls the SDK member directly
-   * rather than through the ORM. The app-side proxy takes index 5 as the stream callback,
-   * so the `{}` at index 4 is read as a config and nothing usable comes back; what is
-   * being read is only whether the start is refused.
-   */
-  async liveStartWithConfig() {
-    const s = await sessionReady;
-    const doc = (await docs.docCreate(
-      s.session_id,
-      "Graph",
-      "data:graph",
-      "store",
-      undefined,
-    )) as Nuri;
-    // Called against the PUBLISHED declaration, which now has these six arguments, so the
-    // widening this used to need is gone: the arity is checked here rather than asserted.
-    // What remains unknowable at compile time is the DEPLOYED engine's arity, which is
-    // the question this asks.
-    try {
-      await realNg.orm_start_graph([doc], [], LIVE_SHAPE, s.session_id, {}, () => {});
-      return { doc, error: null };
-    } catch (e) {
-      return { doc, error: e instanceof Error ? e.message : String(e) };
-    }
-  },
-
   /** The document's own answer: how many triples the seeded subject still has. */
   async liveSeededTriples() {
     if (!probe) return -1;