ci: label PRs with reviewed/wait-merge when auto-merge is enabled

[bircni]

GitHub emits auto_merge_enabled and auto_merge_disabled activity types on
pull_request, so reviewed/wait-merge can follow the auto-merge state
instead of being applied by hand.

pull_request_target is needed to write labels on fork PRs; the job only calls
the label API and never checks out PR-head code.

[silverwind]

Why not merge it into pull-labeler typescript?

[wxiaoguang]

Maybe it could be smarter: only mark one PR with "wait-merge", or only merge one PR in "auto merge" status with main branch.

Otherwise, if there are 5 PRs in "auto merge" status, you will trigger 5+4+3+2+1 times CI runs.

[silverwind]

Maybe it could be smarter: only mark one PR with "wait-merge", or only merge one PR in "auto merge" status with main branch.

GitHub has exactly this feature called "merge queue", if we enable it we don't even need reviewed/wait-merge labels or that bot mechanism.

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

[bircni]

Maybe it could be smarter: only mark one PR with "wait-merge", or only merge one PR in "auto merge" status with main branch.

GitHub has exactly this feature called "merge queue", if we enable it we don't even need reviewed/wait-merge labels or that bot mechanism.

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

good idea

[silverwind]

Will be good if we test that, should later implement this in Gitea too and fix #36392.

[bircni]

Will be good if we test that, should later implement this in Gitea too and fix #36392.

Reminds me that I have a branch for that somewhere 😂🤔