Yes GitHub is slowly reinventing IDEs in their code review tools. If you do it in the IDE with real commits you can use refactoring aids, search+replace etc.

If someone keeps making the same errors and isn't paying attention to the fixes you can just talk about it with them in a meeting, same as with any other recurring problem you might have with a teammate.

The model we implement is hierarchical, so there's no running roughshod over other people by design. If the reviewer isn't happy they won't merge, and you have to keep going until they are. But, it's also on the reviewer to get the work in because they're being held accountable for delivery too, and they can make changes with the same tools as the authors. So it's a collaboration.

What I mean by running roughshod is now it's incumbent on an engineer with lesser power to simply overwrite changes they don't agree with or understand. The chance of them doing that is going to be low unless the change is obviously wrong. One has to appreciate this power disparity on a team of mixed skill levels. It is indeed a real thing. Jrs. should be actively involved in their development, not after the fact have a talking to because they didn't learn.

I've been doing this for 26 years at 15 companies and have led several teams. I can think of some where this would be fine (ie. everyone has a healthy amount of EQ), but I can easily think of several with talented somewhat thorny, highly opinionated sr level engineers where this would be a problem. I've literally had to have a talk with someone on the spectrum who would occasionally do this very thing (ie. just push up a commit w/ a variety of fixes) because he felt it was more expedient than explaining in a PR. The person who complained felt like they were being bullied.