Personally I believe this is one of the major gaps in Scrum, and there is no prescripted way to solve this problem. XP's focus on technical aspects is much better in this regard, but the possibility of runaway technical debt still exists.

There are so many places where this can sneak in and become an issue, too:

- The development team can groupthink, underestimate and/or fail to account for technical debt payback in planning poker. They may estimate the cost for the new feature, but not include any time for refactoring to keep the codebase healthy

- The Scrum Master may not shield the development team from pressure to deliver coming from the product owner, which may cause the team to cut the above corners

- Codebase health may be split out from vertical stories into its own tasks that get deprioritised by the product owner

- Even if the development team identifies the need for codebase health, this may not be communicated back to the product owner in a way that makes business sense ("but we can still get this feature out the door quickly and fix the mess later, right?" - yes, once or twice, but the downside is a slowing of velocity)

- Even if the team started well with ground rules the Scrum Master is supposed to enforce surrounding technical quality, the Scrum Master may not be effective in enforcing the process - either because they lack authority or because they lack the ability or knowledge to do so

Among several others.

In your situation, the big red flag is that the team predicted the issue many months prior. The process has failed to extract that information from the team members and deliver a consensus between them and the product owner.

Though ultimately, as with any project, if the product owner has more organisational authority than the development team and chooses to exert this authority, no process will be able to save you.