fix(app): audit-log-store stress test could trip vitest's internal 60s RPC watchdog on slow Windows CI

The 'caps retained events' test does 5,000+ synchronous
recordEvent() calls with no yield point. On a slow Windows CI runner this
crossed 60s of unbroken synchronous work (61.7s in the v1.4.0 release
build), tripping vitest 3.x's own internal birpc RPC heartbeat — a
hardcoded 60s timeout, independent of and not covered by testTimeout
(only removed in vitest 4, see vitest-dev/vitest#8164/#8297). The whole
run then fails with "[vitest-worker]: Timeout calling onTaskUpdate" even
though every assertion passes. Fixed by yielding to the event loop via
setImmediate every 250 iterations so the RPC channel stays serviced
regardless of total wall-clock time. Applied the same hardening to the
other 5,000+-iteration loop in this file (the addon-gated 2x-cap stress
test) as cheap insurance against the same failure mode.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: voidstackloop

app/src/audit-log-store.test.ts

@@ -39,13 +39,32 @@ describe("audit-log-store", () => {
 
     it(
         "caps retained events instead of growing without bound",
-        () => {
+        async () => {
             // The cap is soft (see MAX_EVENTS/TRIM_BATCH in audit-log-store.ts):
             // the file may transiently hold up to MAX_EVENTS + TRIM_BATCH
             // events between trims, so the loop must actually cross that
             // ceiling for this test to mean anything.
             const iterations = auditLogStore.MAX_EVENTS + auditLogStore.TRIM_BATCH + 10;
-            for (let i = 0; i < iterations; i++) auditLogStore.recordEvent("case-viewed", { targetId: String(i) });
+            // Yielding every YIELD_EVERY iterations is load-bearing, not
+            // cosmetic: this loop is a real, synchronous fs read-modify-
+            // write on Windows CI (see the timeout comment below) and a
+            // fully unyielded synchronous stretch past ~60s trips Vitest
+            // 3.x's own internal worker RPC heartbeat — a hardcoded,
+            // `testTimeout`-independent birpc timeout (default 60s,
+            // unconfigurable pre-Vitest-4:
+            // https://github.com/vitest-dev/vitest/issues/8164) — which
+            // fails the whole run with "[vitest-worker]: Timeout calling
+            // 'onTaskUpdate'" even though every assertion here passes.
+            // `setImmediate` (a real macrotask yield, not just `await
+            // Promise.resolve()`) gives the worker's event loop a chance to
+            // service that RPC channel periodically so the heartbeat never
+            // goes quiet for 60s straight, however long the test's total
+            // wall-clock time ends up being.
+            const YIELD_EVERY = 250;
+            for (let i = 0; i < iterations; i++) {
+                auditLogStore.recordEvent("case-viewed", { targetId: String(i) });
+                if (i % YIELD_EVERY === 0) await new Promise((resolve) => setImmediate(resolve));
+            }
             expect(auditLogStore.listEvents().length).toBeLessThanOrEqual(auditLogStore.MAX_EVENTS + auditLogStore.TRIM_BATCH);
         },
         // With the Rust addon built, recordEvent() appends in O(1) both below
@@ -225,9 +244,24 @@ describe("audit-log-store", () => {
     describe("fast-append path: stress and self-healing", () => {
         it.skipIf(!nativeAddonPresent)(
             "stays correct across multiple trim cycles (2x the cap)",
-            () => {
+            async () => {
                 const iterations = auditLogStore.MAX_EVENTS * 2 + 10;
-                for (let i = 0; i < iterations; i++) auditLogStore.recordEvent("case-viewed", { targetId: String(i) });
+                // Same periodic macrotask yield as the "caps retained
+                // events" test above, and for the same reason: a long
+                // unyielded synchronous stretch here can trip Vitest 3.x's
+                // own internal 60s worker RPC heartbeat independently of
+                // this test's own timeout (see that test's comment for the
+                // full explanation and the upstream issue link). Cheap
+                // insurance even when the addon's O(1) path keeps this fast
+                // in practice — `nativeAddonPresent` only checks that the
+                // addon directory exists, not that it actually loaded at
+                // runtime, so a silent fallback to the slow path here would
+                // otherwise hit the exact same failure mode.
+                const YIELD_EVERY = 250;
+                for (let i = 0; i < iterations; i++) {
+                    auditLogStore.recordEvent("case-viewed", { targetId: String(i) });
+                    if (i % YIELD_EVERY === 0) await new Promise((resolve) => setImmediate(resolve));
+                }
                 const events = auditLogStore.listEvents();
                 expect(events.length).toBeLessThanOrEqual(auditLogStore.MAX_EVENTS + auditLogStore.TRIM_BATCH);