When will m-c be updated with code from Github?
At the end of the current release cycle, likely in the week before soft freeze. Unless we have an emergency, that is. Check our release documentation on WikiMo, especially the "Release Process" section, if you want to learn more.
I would expect a separate Bugzilla issue to track the next release
With the newly created regular merge process, there is no need for that. These bugs are created on-demand to land something, but not in preparation for the cycle. The only cases where we create a bug ahead of time is in case of emergency, i.e. fixing a regression that's tracked by RelMan, fixing a high-profile site, or anything else that requires system addon update rollouts outside of the tree.
but the 7.0.0 commit on Github is associated with an old, already-closed Bugzilla issue
The fact that I had to bump the version number after a change was an oversight. I conditionally r+'ed on the bug asking for the version number to be bumped, but because everyone was in a hurry, that comment was missed. I disappeared for vacation the same day, and yesterday was my first working day again, which is why there is a large time gap.
Version number changes are irrelevant for anything shipped inside m-c. Version numbers matter only if we rollout the addon via the system addon update channels, where the version number must be higher than the version we ship in m-c. As be build the .xpi for rollouts from our GitHub repo, not m-c, I only bumped the version number there and didn't bother with pushing the same change to m-c - the commit will be merged in this cycle anyway.
According to the Github commit history, you've imported various patches from Phabricator
Not quite. I imported patches that were already landed in mozilla-central. I did not import any patches that have not been landed, and we'd never do that. Ideally, this would never be required, because people would never change our sources in m-c directly, but only via the GitHub repo. This is unrealistic, of course, because there are many valid reasons why people do work in m-c instead of GitHub, and it's our job to keep track of that and merge the changes back into our "source of truth" before overwriting them. Doing that is part of the process I've linked earlier, so I'm not concerned about such changes.
This is especially relevant because my patch here uses a method that someone is/was going to remove in
I don't think Tom was aware that you used the method, and there is no reason eh should be. That's why reviews exist, and I would have catched that in said review. I didn't get a chance yesterday, because it was already late, but eh.. :) In the worst case, the commit would have blown CI when merged back into the GitHub repo, at which point we'd be able to correct that. Nothing would have been lost.
I hope I could answer your questions. If not, please do ping me again, I'm happy to help out.