fix: prevent read-only watcher events from causing overflow loops - #152

Reviewed, and ran it on the tree from #151. Thanks for the quick turnaround.

Empirical check — v1.0.7 on the original repro tree (25,360 files, 5,709 watched directories, watch budget 8192), with --watcher-queue-cap removed so it runs at the default 16,384:

• Three full read sweeps of the tree: 201,726 file opens in 6s, roughly 12x the queue cap per sweep. Zero watcher queue overflowed lines and no recovery walks in the log.
• Real changes still land: a new file is searchable ~2s after creation, and a deletion drops out of the index in ~2s.
• Before 1.0.7 this machine needed --watcher-queue-cap 131072 to stay out of the ~1.5s overflow loop. That workaround is now gone from my systemd unit.

Code — the placement looks right. Two things I checked specifically:

• need_rescan() is evaluated before the kind filter. inotify delivers IN_Q_OVERFLOW as EventKind::Any with no paths, so the new filter would otherwise have turned a real kernel overflow into silence. Good to see a test pinning that down.
• overflowed.swap(false, ...) happens before the stale walk rather than after, so edits landing during reconciliation re-arm recovery instead of being swallowed.

Sharing event_changes_index between the callback and handle_fs_event is also what keeps this from regressing later: one predicate instead of two that can drift apart.

One residual item, not a blocker: notify 7.0.0 hardcodes WatchMask::OPEN in its inotify mask (notify/src/inotify.rs#L418-L425) purely to synthesize the Access(Open) events tgrep now always discards. The kernel still queues that traffic, and fs.inotify.max_queued_events is 16,384 by default on most distros. If the notify reader thread ever falls behind on a large tree, IN_Q_OVERFLOW → need_rescan() → recovery walk → the same flood: same loop shape, much harder to reach. Dropping OPEN from the mask would remove the traffic at the source, but that needs an upstream change in notify (or using the inotify crate directly). Happy to open a separate issue if it's worth tracking.