Yes such a job does exist - a company performing due diligence during the acquisition of another company whose main value is in the software they own, should hire a third party to inspect the codebase... I've been asked to do this before for a company that had a large pile of embedded c code, which is my main thing (though after the purchase was agreed.. oops! and it was pretty bad...) and have a friend who has done it a few times with things relating to security of systems...
It's a consulting role, though the biggest issue is that to do it you need to be trusted by your non-technical business employer to have a good idea of what good and bad code is. And your non technical business employer needs to know that this is even a thing that they can and should do as part of the acquisition process... Also, as far as the reporting goes it can be very hard to estimate the looming cost of fixes, as you obviously don't have time to read and fully understand thousands upon thousands of lines of code - so you basically need to report qualitative opinions.
Now, what happens with the opinions - basically there should already be data on current rate of bugfixes and the current issue backlog, that's understandable at a business level - So the codebase quality informs the new owners how much effort they will need to factor in to driving a new commitment to cleaning it up slowly, over time. And how long they might need to wait before they can start to see an overall faster development time than the previous management had achieved.