fix(test): 用排空微任务代替 250ms 睡眠

`finalises the stream exactly once` 在本地过了 8 次,在 macOS CI 上失败。
那个门跑的是整个 50 文件套件,机器负载高,而测试用 `setTimeout(250)` 等
`finally` 跑完 —— 时间预算不是这个测试能花的东西。

要等的不是一个时刻,是一串确定的微任务跳数:abort listener,然后
`await iterator.next()` 的延续,循环的 break,再 `finally`。跳数是确定的,
时钟不是。所以数微任务,再补一次 setImmediate(socket close 到 abort
listener 走的是宏任务队列,不是同一个)。

这条测试的作用是「双重收尾时会转红」,一个靠睡眠成立的断言在机器忙的
时候会自己红掉,那它守的就不是它声称的东西。

整套 933 连跑 3 次全过。

Author: probe

packages/webui/test/unit/webui-service.test.ts

@@ -1015,9 +1015,20 @@ describe("WebUI service", () => {
       pullSettled,
       "the parked pull to settle after the socket closed",
     );
-    // Real room for the `finally`: a second `return()` would land well after a
-    // couple of microtask turns.
-    await new Promise<void>((resolve) => setTimeout(resolve, 250));
+    // Drain the microtask queue instead of waiting on a clock.
+    //
+    // The `finally` that could double-finalise is not on a timer: it runs a few
+    // microtask hops after the parked pull resolves — abort listener, then the
+    // `await iterator.next()` continuation, then the loop's `break`, then the
+    // `finally`. Counting microtasks is deterministic; a sleep is not. The
+    // 250 ms this used to wait passed locally 8 times and failed on CI, where
+    // the whole 50-file suite loads the machine and the clock is simply not a
+    // budget this test can spend.
+    for (let i = 0; i < 64; i += 1) await Promise.resolve();
+    // One macrotask hop as well: `setImmediate` callbacks and promise
+    // continuations are not the same queue, and the socket `close` handler
+    // reaches the abort listener through the former.
+    await new Promise<void>((resolve) => setImmediate(resolve));
     // The count is the point. Asserting only `returnCalls >= 1` would pass
     // against a double-finalise, which is the failure this pins shut.
     expect(returnCalls).toBe(1);