Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/blast-hardcheese/turborepo-cache-bug

Which canary version will you have in your reproduction?

2.5.7-canary.0

Environment information

turbo 2.5.7-canary.0

CLI:
   Version: 2.5.7-canary.0
   Path to executable: /private/var/folders/3r/7tfjkjpj4b5b66x3sch6z5kr0000gn/T/xfs-7c1f70d7/dlx-54643/.yarn/unplugged/turbo-darwin-arm64-npm-2.5.7-canary.0-4f797067dc/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: berry

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 5217
   Available CPU cores: 12

Environment:
   CI: None
   Terminal (TERM): screen-256color
   Terminal program (TERM_PROGRAM): tmux
   Terminal program version (TERM_PROGRAM_VERSION): 3.5a
   Shell (SHELL): /run/current-system/sw/bin/bash
   stdin: false

Expected behavior

turbo run ... with hundreds of cached files included via tasks' outputs: [ .../** ], should not generate an inotify event for every single cached file, only for ones that legitimately have changes.

Actual behavior

Hundreds of spurious inotify change events which cause services booted with file watching enabled to get stuck in a shutdown/startup loop until the queue of inotify events is cleared.

To Reproduce

In the example repository, with turbo remote caching link'd, run yarn watch-for-bug in one terminal and yarn run turbo-build or yarn run turbo-build --force in another terminal, observing that despite the output file contents never changing, "modified" events are emitted for every file the first time "Full turbo" is triggered.

Additional context

Turbo is a fantastic tool, this particular issue definitely tripped me up. Thank you for your consideration