fs: Cool down after macOS FSEvent stream failures

[vxio]

Hey Zed team!

Problem

When I have several semi-large project/repos open in Zed, everything keep freezing up even after I would Force Quit and restart.

Debug and logs

The app log repeatedly printed unable to start FSEvent stream for many watcher registrations before restart. The native watcher cooldown path already handles notify::ErrorKind::MaxFilesWatch, but on macOS this failure can surface as notify::ErrorKind::Generic("unable to start FSEvent stream"), so those registrations keep retrying instead of backing off.

The relevant local log pattern was:

2026-06-18T11:44:18-07:00 WARN  [fs] Failed to watch <go module cache path>/model_transfer_authorization.go:
unable to start FSEvent stream
2026-06-18T11:45:09-07:00 WARN  [fs] Failed to watch <workspace path>/events:
unable to start FSEvent stream
2026-06-18T11:45:09-07:00 WARN  [fs] Failed to watch /Users/vince/Brewfile:
unable to start FSEvent stream
2026-06-18T11:45:09-07:00 ERROR [crates/worktree/src/worktree.rs:3311] failed to add common directory to watcher: unable to start FSEvent stream
2026-06-18T11:45:09-07:00 ERROR [crates/worktree/src/worktree.rs:3315] failed to add repository directory to watcher: unable to start FSEvent stream
2026-06-18T11:45:10-07:00 ERROR [crates/worktree/src/worktree.rs:5096] unable to start FSEvent stream
...
2026-06-18T11:46:23-07:00 ERROR [crates/worktree/src/worktree.rs:5096] unable to start FSEvent stream
2026-06-18T11:46:24-07:00 INFO  [zed] ========== starting zed version 1.8.0+dev.57ebf08565cfcf20e2440f66a9f681e7921d11c7, sha 57ebf08 ==========

That run had 391 consecutive unable to start FSEvent stream failures between 11:45:10 and 11:46:23, followed by a Zed restart.

This treats that macOS-specific error the same as the existing native watch-limit case and adds a regression test for the cooldown behavior.

Related to #57042 and #58678.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• Fixed repeated macOS filesystem watcher registration attempts after FSEvent stream failures.

[etiennechatreaux]

Hit the same error signature on macOS — in my case the FSEvent stream failures came from fd exhaustion after days of uptime, and the 2s retry loop kept hammering the exhausted process. I filed #62486 with the full diagnosis (including what leaks the watchers in the first place), and opened #62489 which bounds the retry loop with a backoff. Your cooldown classification and that backoff look complementary to me: yours gates new registrations for this specific failure, mine slows the per-path retry for any registration error.