feat(filters): distinguish author and commenter in search filters

[afonsojramos]

Summary

The author: search filter matched subject.user, but enrichment sets subject.user to the latest commenter (for the avatar), not the thread author. So author:coderabbitai as an exclude hid review requests on human-authored PRs whenever the bot left the last comment, and the filter named "author" was really matching commenters.

This splits that conflated identity into two distinct, forge-agnostic roles on the notification subject:

• author: who created the thread (pull request / issue / discussion / release / commit)
• commenter: who left the latest comment, when there is one

subject.user stays as the derived display identity (commenter ?? author), so the avatar and the user-type filter are unchanged. The search qualifiers now read these roles directly:

• author: matches the thread author
• commenter: (new) matches the latest comment author

The filter layer no longer inspects GitHub notification reasons, so it stays generic across forges. For commit notifications the commit author and the latest comment author are fetched in parallel, so both roles are populated without extra latency.

Closes #2914

[setchy]

I've been thinking about this FR...

GitHub UI doesn't distinguish between author or commenter, since notifications always show the latest state - so I was tempted to close the FR as unplanned...

That said, alternatively, we could look to change the filter include/exclude tokens to support author: and commenter: prefixes which could search on the two different user attributes.

I'm not sure I'm a fan of changing the filter based on the notification subject code

[afonsojramos]

@setchy fair... It is also forge specific code that is leaking A LOT tbh

[afonsojramos]

Reworked this to drop the reason-based approach and go with the author: / commenter: split you suggested, @setchy.

Enrichment now exposes two distinct roles on the subject (author for the thread creator, commenter for the latest comment author), and the filter qualifiers read those directly instead of branching on the notification reason. subject.user stays as the display identity (commenter ?? author), so avatars and the user-type filter are unchanged. The filter layer no longer touches GitHub reasons, so the forge-specific leak is gone too.

Net effect:

• author: matches the actual author now, so excluding a bot no longer suppresses review requests where it only commented last (the original report).
• commenter: is the new lever for the bot comment noise case.

Two caveats with the current implementation, however:

1. commenter: is a hammer on a screw, since we no longer reason about why a notification arrived it will also hide a human PR where the bot happened to comment last even if you were review requested.
2. Commit notifications only populate one of the roles, since we fetch either the comment or the commit, not both.

[afonsojramos]

Followup: managed to fix the commit caveat. Commit notifications now fetch the commit and its latest comment in parallel, so both author and commenter are populated like the other types

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[afonsojramos]

So, final caveat: If one excludes commenter:coderabbitai, a teammate opens a PR and requests a review, then CodeRabbit auto-comments after the request and becomes the latest commenter. That review-request notification gets hidden even though you were asked to review. But maybe this is a disadvantage of excluding bot comments? Or an incentive to be selective of which commenters to exclude. But, to be honest, this was already the case, so nothing new.

Before: author: was the only tool, it secretly matched the last commenter, and you had no way to avoid that. Every user of that filter hit the bluntness.

Now: author: matches the real author, so it’s precise and no longer drops review requests. The old blunt “match whoever commented last” behavior still exists, but only if you deliberately reach for commenter:.

[setchy]

Thanks @afonsojramos.

Let me soak on this a bit.

We also have a Bot filter which includes dependabot, renovate, netlify. I wonder if we should expand that