Fix flaky 64 MiB image materialization test on Windows CI (#8198)

The responsiveness test timed wall-clock gaps between 1 ms ticks, which reached 50.35 ms on the shared Windows runner for the same code. It now measures main-thread CPU time between ticks and still fails when the payload decodes in one chunk.

packages/server/src/server/agent/providers/provider-image-output.test.ts

@@ -184,17 +184,24 @@ test("repeated content is reused without rewriting the attachment", async () =>
 test("64 MiB materialization leaves the event loop responsive and preserves bytes", async () => {
   const bytes = Buffer.alloc(64 * 1024 * 1024, 37);
   const data = bytes.toString("base64");
-  let previous = performance.now();
+  // Main-thread CPU time between ticks bounds the decode and hash work done on the loop;
+  // wall-clock gaps on shared CI runners also count preemption and timer granularity.
+  // File writes stay on fs/promises, so they never block the loop.
+  const threadCpuMs = () => {
+    const { user, system } = process.threadCpuUsage();
+    return (user + system) / 1000;
+  };
+  let previous = threadCpuMs();
   let longest = 0;
   const probe = setInterval(() => {
-    const now = performance.now();
+    const now = threadCpuMs();
     longest = Math.max(longest, now - previous);
     previous = now;
   }, 1);
   try {
     const result = await materializeProviderImage({ data, mimeType: "image/png" });
     await new Promise((resolve) => setTimeout(resolve, 5));
-    console.log(`64 MiB attachment longest loop gap: ${longest.toFixed(2)} ms`);
+    console.log(`64 MiB attachment longest blocking stretch: ${longest.toFixed(2)} ms CPU`);
     expect(longest).toBeLessThan(50);
     expect(readFileSync(result.path).equals(bytes)).toBe(true);
     rmSync(result.path, { force: true });