I was the user doing the job. As I heard from this meta post, I stopped the activity on the spot.
As a precaution, I stopped it also on other sites, where it didn't cause any negative feedbacks, and the edit suggestions were quickly accepted.
A more recent comment in the related MSE post, from an SE insider, indicates that an automatized solution from the SE to the problem likely won't happen in the foreseeable future. It has a technical reason: the fixup, what they used, use their internal elastic search engine, which doesn't index the tag wikis. Thus, the suspection that it could be done easily by improving their http -> https conversion script, is unfortunately false.
I collected the tags containing internal http links with this, since then a little bit improved SEDE query.
On the Android SE, there are around 110 tag wikis back. On most other sites, particularly on smaller betas, I could finish the task in a single rush.
A user, without tag wiki edit privilege, can have at most 5 edit suggestions coincidently (20 on betas). Over it, the "edit" link doesn't appear in the tag wiki pages any more. The "Submit" clicks on the already edited tag wikis fail with an error message. In my opinion, this flow control should be enough to defend the review queue from an overload, but I accept the community consent.
Anybody having the tag wiki edit privilege could finish the job without loading the review queue. You can get the list of the tag wikis to fix by the refered SEDE query. This is not really the funniest task working with computers, but the data to process is really not too big. And once it has to be done.
I am sorry for the trouble - hopefully I will be more productive for you in the near future, with real, positively scored, main site posts. :-)
P.s. the small count of the problematic tags avoids to get any significant rep/badges with the edits. Beside that, I edited not only the main, but also on the meta sites.