Back off retries when file watch registration keeps failing

[etiennechatreaux]

Objective

Part of #62486: when watch registration keeps failing (in that issue, FSEvent stream creation failing after fd exhaustion on macOS), poll_path_until_created retries the same path every 2 seconds forever — no backoff, no cap. On an already-degraded process this spams the log (267 warnings in the 10 minutes before log rotation killed the log) and keeps hammering a resource that is already exhausted.

This does not fix the watcher leak that causes the exhaustion in the first place (see the retention chain posted on the issue); it stops the retry loop from making a degraded process worse. Related: #59571 takes a complementary route for the same error signature (classifying the macOS FSEvent failure into the native watch-limit cooldown); this PR bounds the per-path retry loop itself, for any registration error on any platform.

Solution

Double the retry delay after each failed registration attempt, capped at 60 seconds. The base interval stays poll_interval() (2s by default), so the common case — polling for a path that doesn't exist yet — is unchanged, and the first sleep is identical to before. The delay only grows on the Err arm, and the warning now says when the next retry happens.

To make the failure path testable, the registration function is now a parameter of poll_path_until_created (it previously called register_existing_path directly, which goes through the global_watcher() static, so a fake backend couldn't be injected into the poll task).

Testing

• Added failed_watch_registration_retries_with_backoff: drives the poll task with an injected registration function that always fails, and asserts the exact backoff schedule (2s, 4s, 8s, … capped at 60s) with a single attempt per interval, on the deterministic test executor.
• cargo test -p fs --lib fs_watcher::tests: 16 passed. pending_path_is_registered_once_created covers the success path (first poll still fires at poll_interval()).
• Ran on macOS (where File watcher leak on macOS: fd exhaustion and endless "unable to start FSEvent stream; retrying" loop after days of uptime #62486 was diagnosed); the change itself is platform-independent.

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:

• Improved file watcher error handling to back off exponentially when watch registration keeps failing, instead of retrying every 2 seconds forever.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @etiennechatreaux on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[etiennechatreaux]

The clippy_* failures were a redundant_clone in the new test (cx.executor().clone() — TestAppContext::executor() already returns a BackgroundExecutor by value). Fixed in 3d1a549.

Verified locally with the CI command on the pinned toolchain (./script/clippy -p fs, rustc 1.97.1): clean, and fs_watcher::tests still 16/16. The new workflow runs are waiting for approval.