This looks good to me!
(One caveat is that I don't actually use the : notation with Git myself, but I think I understand it.)
Re:
I don't have a strong opinion; I can see advantages on both sides. If we did opt to merge stable into master, you have a good point that we should probably edit the commit message to be explicit that it's a "fake" merge.
But actually, I think we don't need to make a final decision until after this release. Once you push v8.7 and stable, we'll presumably see this effect @elibarzilay pointed out:
If that creates noise in the UI or it otherwise seems desirable to do the "merge-stable-into-master-after-release" variant, we could do git switch master && git merge -s ours stable && git push any time before branching for the 8.8 release. Otherwise, we do nothing and stick with the "merge-with-the-release-branch-when-its-created" strategy.
On this part:
I agree it doesn't seem like a big deal either way, but I think I slightly prefer having git merge -s ours stable at the beginning of the release branch rather than the end so that the tag and branch end up pointing to a commit like Update version number for the v8.5 release · racket/racket@9d228d1 · GitHub with a nice message rather than a fake merge commit.