So in effect, unauthorized merges (PR looking merged; email notifications being sent) are possible if they are "zero-commit-merges" that don't actually change any state in the git repository.
So in effect, unauthorized merges (PR looking merged; email notifications being sent) are possible if they are "zero-commit-merges" that don't actually change any state in the git repository.
Thus, in the underlying data structure behind the GitHub interface, there really isn't an "event" here to identify. The PR branch points to the same commit as the base branch, therefore both branches are in the state of existing as "merged" with one another.
So GitHub would have to track changes to the PR branch that result in this state separately from the existing "merge from GUI" and "push PR branch to master" changes, which I could imagine is fraught with edge cases that could result in what you consider a merge event ending up as a closed event.