fix(fsevent): stop the run loop via a CFRunLoopSource to avoid a shutdown race

[Anthony-Eid]

Brings zed-industries/notify up to current notify-rs/notify main and adds our FSEvents run-loop shutdown fix on top. The same fix commit will be proposed upstream separately.

The fix

CFRunLoopStop only takes effect while the target run loop is actually running. The FSEvents watcher thread publishes its run-loop handle and then enters CFRunLoopRun, so a concurrent stop() can call CFRunLoopStop in the window before the loop starts. That stop is lost, the thread parks forever, and the join() in stop() deadlocks. Under heavy event load the loop may also never reach a "waiting" state, so waiting on that is unreliable too.

This replaces the atomic stop flag plus direct CFRunLoopStop with a custom CFRunLoopSource, created and added to the watcher thread's run loop before its handles are published. stop() signals the source and wakes the loop; the source's perform callback then calls CFRunLoopStop from inside the run-loop thread, where it cannot be lost. Because source signals stay pending until processed, a stop that arrives before CFRunLoopRun is entered still stops the loop once it starts.

Tests

Adds a deterministic test that a pre-run stop signal still stops the loop, and a rapid watch/unwatch stress test that previously hung. All fsevent tests pass, and clippy reports no new warnings versus upstream.