Fix flaky daemon log test on Windows

[epeicher]

Related issues

• Related to the Windows unit-tests CI failure (build 17839)

How AI was used in this PR

Claude diagnosed the failing Windows CI log, traced it to a timing race in the daemon log test, wrote the polling fix, and verified lint, typecheck, and the test suite locally. I reviewed the changes and iterated to prevent re-creating the waitFor function.

Proposed Changes

The Windows unit-tests job was failing on a single test — ProcessManagerDaemon > starts a process, emits events, and writes logs — with expected '' to contain 'fixture-stdout'.

The test wrote to a child process's stdout/stderr, waited a fixed 25 ms, then synchronously read the log file. But the daemon's write path is fully asynchronous: child output is piped through readline, then into a buffered WriteStream that must open() the file before flushing. On the slower Windows CI agent the file gets created (so the read returns an empty string rather than throwing) but the buffered bytes haven't flushed within 25 ms, so the assertion fails. The other ~2000 tests pass; this is purely a test-timing flake, not a product bug — in production the streams stay open and flush continuously.

This replaces the fixed sleep + single read with a small poll-until-content helper (2 s cap), making the assertion deterministic across platforms. The broadcastEvent assertions are unchanged, since those events fire synchronously during the request and were never the flaky part.

Testing Instructions

• npm test -- apps/cli/tests/daemon.test.ts passes.
• The previously failing case is ProcessManagerDaemon > starts a process, emits events, and writes logs; it now waits for the flushed log output instead of guessing with a fixed delay, so it no longer races on Windows.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wojtekn]

The change sounds reasonable. I rerun the Windows unit test as it failed 🫣, but it seems it happened due to another reason.

[wojtekn]

Nit: we use a default polling interval of 50ms. Would it make sense to use a longer one?

[epeicher]

This value is the total time the test will wait for the expectation to pass before failing, the polling interval for the waitFor has a default of 50 ms docs here so that's coherent with existing functionality.

[wojtekn]

Yes, the question was whether we need to poll every 50ms.

[epeicher]

Ahms, sorry I misunderstood. I actually don't know, but I think this should be completed in ms so 50 seems reasonable, do you think we should it increase it to maybe 100ms? I don't mind either case.

[katinthehatsite]

The changes look good and the test is passing now 👍