test: elargir la marge du test de latence du repli borne

Le test mesurait un ecart de 35 ms (repli de 60 ms, borne a 25). Ce qu'il
constate est la difference entre « a attendu la barriere » et « n'a pas
attendu du tout » ; 200 ms de repli et une borne a 60 laissent 140 ms
entre les deux, ce qui tient sur une machine chargee. La mutation qui
doit le tuer le tue toujours.

packages/polyfill/test/open-repo.test.ts

@@ -447,7 +447,9 @@ describe("ensureRepoOpen", () => {
       sparql_update: mock(async () => undefined),
     };
     inject(ng as unknown as ReturnType<typeof makeFakeNgWithSubscribe>);
-    setOpenTimeoutForTests(60);
+    // A WIDE fallback on purpose: what is measured is a difference between "waited the barrier
+    // out" and "did not wait at all", and the two must stay far apart under a loaded runner.
+    setOpenTimeoutForTests(200);
     const doc = "did:ng:o:never-answers";
 
     let at = Date.now();
@@ -457,8 +459,8 @@ describe("ensureRepoOpen", () => {
     await ensureRepoOpen(doc);
     const again = Date.now() - at;
 
-    expect(paid).toBeGreaterThanOrEqual(50); // the first read waits the barrier out
-    expect(again).toBeLessThan(25); // every later one does not
+    expect(paid).toBeGreaterThanOrEqual(150); // the first read waits the barrier out
+    expect(again).toBeLessThan(60); // every later one does not - 140ms of margin between them
     expect(doc_subscribe).toHaveBeenCalledTimes(1); // and no second call was ever placed
     // Not authority either way: nothing has been heard from this document.
     expect(getSyncState(doc)).toBe("timed-out");