Lock major change issue after it as been accepted

[Urgau]

Some people continue to post on closed major change despite our messages not to do so.

Let's be more decisive and lock the issue once the major change has been accepted (we tried locking from the started but that had to be reverted #1876).

cf. rust-lang/compiler-team#932 (comment)
cc @apiraino

[Kobzol]

Have you tried if closed issues can be locked through the API? Just something that came to mind. Other than that LGTM, but I'd like to hear what apiraino thinks.

[apiraino]

What changed since the last time we decided to revert the lock?

[Urgau]

Have you tried if closed issues can be locked through the API?

I haven't, but I see no reason it wouldn't work.

What changed since the last time we decided to revert the lock?

People started posting on closed MCP (see rust-lang/compiler-team#932 (comment) or rust-lang/compiler-team#920 (comment)), and last time we lock the issue but did it from the start (which caused issue for non org PR author members), this proposal only does it after it's closed/accepted which doesn't have the same issue.

[apiraino]

By looking at compiler-team#920, I wonder what happens to issues crosslinking/mentions: can a locked GitHub issue show when it is referenced somewhere else?

Other than that, I am mostly neutral about this change - we can try it if you feel strongly about it.

[Urgau]

can a locked GitHub issue show when it is referenced somewhere else?

Yes, the two thing that locking prevents is commenting and using emojis on it. Mentions still works as expected.

we can try it if you feel strongly about it

I wouldn't say I feel "strongly" — "frustrated" might be a better word, posting on an old issue should never be done, in particular for MCP where we have a dedicated place to discuss those.

I don't see any harm in trying it, let's see how it goes.