test(sync): bump flushWatchSetup ceiling 50 -> 250 to end whack-a-mole

The per-test bounded wait loops in the previous two commits only patched
the two flaky call sites we had already seen. Another sibling test in
the same describe block ("reloads sync config when .deepl-sync.yaml is
one of the changed files") surfaced with the identical TypeError on
Node 22 CI immediately after.

Raise the helper's iteration budget at the source instead of adding a
third bounded loop. Each round is two zero-work awaits (sub-microsecond),
so 250 has negligible cost but absorbs the Node 22 + CI worker-contention
tail that was pushing the setup chain past 50. Tests still fail loudly
if setup never completes — the safety ceiling is just larger. The
earlier bounded loops stay in place as belt-and-suspenders and as
diagnostic breadcrumbs (they surface a clear length assertion rather
than a misleading TypeError).

Author: sjsyrek

tests/unit/sync/sync-command.test.ts

@@ -794,11 +794,12 @@ describe('SyncCommand', () => {
     // fake timers, flushing that chain requires alternating microtask drains
     // (`await Promise.resolve()`) with zero-duration timer advances — timers
     // advance queued macrotasks, Promise.resolve drains microtask-only awaits.
-    // 50 rounds is well above the ~10-level await depth of the setup chain,
-    // giving parallel-load runs headroom (the previous 20-round count flaked
-    // intermittently under heavy jest worker contention).
+    // History: 20 rounds flaked → 50 rounds flaked under Node 22 CI worker
+    // contention (sync-command.test.ts in PR 44). 250 gives ample headroom
+    // (each round is sub-microsecond) without hiding real hangs — tests still
+    // fail loudly if setup never finishes, just with a longer safety margin.
     async function flushWatchSetup(): Promise<void> {
-      for (let i = 0; i < 50; i++) {
+      for (let i = 0; i < 250; i++) {
         await Promise.resolve();
         await jest.advanceTimersByTimeAsync(0);
       }