So how have you solved this problem in the past?
That is a social problem not a technical one.
You need to sell the idea to your team to try to improve the code base with every commit you do. Every time you need to make changes in some source file, see what clean up you can do to it as well.
Depending on the morale/motivation/priorities of the team, this can be a harder sell than it should be.
Lead by example. Show good judgement on how much to do. Small changes accumulate fast. Don't upset/hinder people by changing vast tracts of code that they need to work on.
As a great VP of Engineering I once had the fortune to work with told me: Software engineering is a team sport.
Sure, a mass refactoring is going to cause a lot of pain to merge in, but you shouldn't be making massive pull requests in the first place. I don't think small refactoring here and there should be an issue. It's not like we've never dealt with merge conflicts before.
If your company is discouraging refactoring because it will cause merge conflicts, that's probably not a good sign of things to come.
In past I've done one big tabs to spaces, trim line ending whitespqce, cr ln to ln, indent cleanup commit. Hardly anyone can object to that!
So far as comments I've create multi page wiki documents of the high to medium level architecture. A trail of breadcrumbs in the maze for the next guy/gal.
Problem is, those efforts take a lot out of me personally, that stuff sticks in my head years later. Not fun to have the crap i worked on 10 years still on there, I NEED that space :)