Please don't do this. If it's one team's job to clean up the messes other teams leave, you've created a terrible incentive for other teams around working clean.

I remember one place where each project had a fixed-in-advance schedule and engineers were rotated among projects based on whoever was available when the project officially started. Since people rarely worked in the same area of the code base from project to project, the incentive was to get something working and then GTFO. The code of course got steadily worse. So then the company would compensate with major rewrites of the most garbage-y sections.

You want to avoid refactoring if no one else is going to test the change, or if your automated test coverage on the module isn't too good. It's too easy to introduce changes that won't be noticed before deployment.

Chances are most code already works well enough even if the design or code is suboptimal - often the system only changes in certain parts and changes there often. If you can identify the parts of your system that are likely to change due to changes in scale or business requirement, than that is a natural area to focus on in future redesigns or refactoring.

To that end, keep cleaning as you go. And accept that good development can be like a good batter. Probabilistically good. Not certain.