processes.watch: Drain queued watch events before restarting processes

[hencjo]

DISCLAIMER: Both bug triage, fix and most of this summary is AI Generated (Codex 5.4).

Summary

This fixes a restart storm issue in the native process manager where a single file-save burst could cause multiple back-to-back process restarts.

Before this change, the supervisor restarted as soon as it received one watch event, but it did not drain additional already-queued file watcher events first. In practice, one logical change could generate several filesystem events, so the process could restart repeatedly for what was really just one edit.

No cooldown or arbitrary sleep-based debounce was added. The fix is purely queue draining.

User impact

Users could see:

• repeated restarts after saving a file once (> 1000 for me).
• unstable devenv up behavior when editors emitted multiple filesystem events
• restart loops that felt random, especially when watching directories instead of single files

Root cause

The file watcher debounced raw events into batches, but it still forwarded matching paths one-by-one. The supervisor treated every received watch event as an independent restart trigger.

That meant a single save operation could look like:

• first event arrives -> restart
• queued sibling events still pending -> restart again

Fix

When the supervisor receives a file watcher event, it now:

1. consumes the triggering event
2. drains all already-queued watch events
3. performs a single restart

This keeps behavior deterministic without introducing timing hacks.

Tests

Relevant watcher and supervisor test suites pass after this change:

• cargo test -p devenv-event-sources fs::tests:: -- --nocapture
• cargo test -p devenv-processes supervisor -- --nocapture