test: Increase requireTrueWithinDuration timeouts in ldfilewatch tests

[devin-ai-integration]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

• Flaky CI on Windows for TestNewWatchedFileMissing and TestNewWatchedFileDataSource (observed on PR #365, Windows Go 1.25 and Go 1.26 jobs)

Describe the solution you've provided

Increases the requireTrueWithinDuration timeout from 1s to 3s in two tests:

• TestNewWatchedFileDataSource (line 156) — waits for a flag update after file modification
• TestNewWatchedFileMissing (line 189) — waits for a flag to appear after a missing file is created

On Windows, fsnotify uses ReadDirectoryChangesW, which can deliver filesystem notifications with higher latency than Linux's inotify. Combined with -race detector overhead, the 1s window is too tight and causes intermittent failures. The sibling test TestNewWatchedDirectoryMissing already uses a 2s timeout for the same reason; 3s provides additional headroom.

Describe alternatives you've considered

• Do nothing: the Windows checks are not marked as required, but the red CI noise is confusing for contributors.
• Skip on Windows: eliminates noise but loses coverage.
• Channel-based signaling instead of polling: more robust but a larger refactor of the test infrastructure.

Human review checklist

• Verify no other requireTrueWithinDuration calls with tight timeouts were missed (there is one more at line 229 which already uses 2s)
• Confirm 3s is a reasonable upper bound — not so high that a real regression takes too long to surface

Link to Devin session: https://app.devin.ai/sessions/d3cef2cb9a624014baff3d51440b6715

---

Note

Low Risk
Low risk: test-only change that relaxes polling timeouts to reduce flakes; no production logic is modified.

Overview
Increases requireTrueWithinDuration timeouts from 1s to 3s in TestNewWatchedFileDataSource and TestNewWatchedFileMissing to give more headroom for filesystem watcher latency (notably on Windows) when waiting for flag updates after file creation/modification.

^{Reviewed by Cursor Bugbot for commit 15c9723. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[aaron-zeisler]

This is a reaction to CI failing on this PR: #365

I audited CI failures to understand if the 2-second timeout in the existing TestNewWatchedDirectoryMissing() test is good enough. That test hasn't failed at all in the past 90 days, so it seems good.

[kinyoklion]

This might help, but I have generally found there to be flaws with the test methodology for these file watcher tests. Just don't be surprised if there continue to be flakes. Basically assumptions with how many times file modifications will be generated (where windows will rate limit and coalesce them), the granularity of the timestamps (two updates within the same granularity and ignoring one), the handling of failed partial states (JSON parsing causing us to stop watching the file, even though it was just because of a partial flush).