Filter uninteresting file watcher events at context ingress

[rootvector2]

Description

This change implements early filtering of file watcher events in the analysis server to reduce unnecessary work and improve performance.

Currently, all watcher events are queued and processed, even for files that are not relevant to analysis. This PR updates the event handling logic to drop uninteresting events at the point of ingress based on analyzer context relevance.

What this PR does

• Filters file watcher events early using contextRoot.isAnalyzed(path)
• Ensures only events for files within analyzed contexts are processed
• Preserves all behavior for relevant files (e.g., Dart sources and analyzed workspace files)
• Avoids introducing custom file-type allowlists to prevent drift from analyzer logic

Important details

• No scheduler-level deduplication is introduced (to avoid ordering/semantic risks)
• Filtering is based entirely on analyzer context, not file extensions
• REMOVE events are still allowed to ensure proper cleanup and state consistency

Why this change

As discussed in the issue, many watcher events are not relevant to analysis and can be dropped earlier to reduce load on the analysis server. This change aligns with that goal while keeping correctness and existing behavior intact.

---

Related Issue

Fixes: #62805

---

Testing

Added/updated tests to verify:

• Events outside analyzed context are ignored
• Events inside analyzed context are processed correctly
• Irrelevant events do not block subsequent relevant events

All updated tests pass locally.

---

Notes

This change keeps the implementation minimal and aligned with existing analyzer behavior by relying solely on context-based filtering instead of introducing new heuristics.

---

Checklist

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

[copybara-service]

Thank you for your contribution! This project uses Gerrit for code reviews. Your pull request has automatically been converted into a code review at:

https://dart-review.googlesource.com/c/sdk/+/488760

Please wait for a developer to review your code review at the above link; you can speed up the review if you sign into Gerrit and manually add a reviewer that has recently worked on the relevant code. See CONTRIBUTING.md to learn how to upload changes to Gerrit directly.

Additional commits pushed to this PR will update both the PR and the corresponding Gerrit CL. After the review is complete on the CL, your reviewer will merge the CL (automatically closing this PR).

[copybara-service]

CL has new comments, please view and respond to them in Gerrit.

If a reviewer requested changes, push new commits to this PR and it will be automatically copied to Gerrit. After that you can mark reviewer comments as resolved in Gerrit and request another round of reviews.

Note: when you add comments in Gerrit they only become visible after you send them by clicking Reply and Send.

[copybara-service]

Gerrit CL has build or test failures as well as new comments, please review them in Gerrit.

You will need to address both the comments and the failures before requesting another review.

If a reviewer requested changes, push new commits to this PR and it will be automatically copied to Gerrit. After that you can mark reviewer comments as resolved in Gerrit and request another round of reviews.

Note: when you add comments in Gerrit they only become visible after you send them by clicking Reply and Send.

[copybara-service]

Gerrit CL has build or test failures as well as new comments, please review them in Gerrit.

You will need to address both the comments and the failures before requesting another review.

If a reviewer requested changes, push new commits to this PR and it will be automatically copied to Gerrit. After that you can mark reviewer comments as resolved in Gerrit and request another round of reviews.

Note: when you add comments in Gerrit they only become visible after you send them by clicking Reply and Send.