You and your PO have conflicting uses for the backlog, which need to be reconciled.
You want a list of every good idea that anyone has ever had. Perhaps above a certain threshold of good, since you're calling it "tech debt" rather than just "potential improvements".
Your PO wants something that you can look through on a regular basis to choose tickets: a realistic and manageable list of what actually needs doing. Your increasing tech debt is not quite the same as "low priority", though, because to the PO a low priority ticket in the backlog means something that's still worth periodically reviewing and perhaps raising its priority. Your PO strongly believes that for these tickets it's not worth doing even that.
You are also concerned that something in the backlog might secretly be really important, since it points to an area that might rot. If you had time to do all of these tickets, then maybe you could deal with every potential point of failure that you've identified. But you do not have time, which is why you prioritize. The things that are persistently not prioritized have a low(er) chance of causing serious failure, and hopefully a genuinely low chance of causing failures that will not be caught in testing in the event that they do happen.
So, by not prioritizing them you have decided not to do them. "We're not going to do this any time soon" means, "we're not going to do this ever, unless it gets worse". It doesn't literally mean that, but be honest with yourself: that's what happens.
So, own that decision. Other than maybe a small sample pulled out for one reason or another (like, it's mid-afternoon, you're going on vacation, and there are no small tickets left in the sprint) you're not going to do these tickets any time soon. Unless you link them to higher-priority symptoms you very likely aren't going to do them ever. You should not be grooming these nuisances every sprint.
If your backlog doesn't satisfy both needs then that is an issue with your issue-tracking system, that needs to be solved in a way your issue-tracking system supports:
Tag them "slush pile" and exclude the tag from the view used for the majority of your planning. Then include it back in when someone joins the team and you're filtering the entire backlog for "tickets that a novice could tackle before lunch" to get them started.
Close them with a "won't fix" resolution, so that they're still searchable if they contain any useful insights how to address the issue identified. OK, so it's embarrassing if you eventually re-open or duplicate a "won't fix" ticket and actually fix it, because that means you were "wrong" when you predicted you wouldn't. But should it be more embarrassing than never fixing hordes of tickets you predicted you would fix?
Move them to another "code improvements" project. You can occasionally look at this to assess whether it's time to focus a sprint on some developer quality-of-life issues that will improve future efficiency, or on some ticking time-bomb issues (like Y2K, or the tiresome inevitability that for every dependency you have, some day upstream will release a critical security fix which is not back-ported to the version you're using).
Define more priority levels, hide the lowest level from the default backlog view, and make a rule that you do not waste your time looking at those tickets unless you run into them for some reason other than, "they're on the list".
In all of these approaches, the basic idea is that you keep them on your backlog (used for recording everything you know about the state of the product), and remove them from your PO's backlog (used for sprint planning).
Anyway I suspect the root issue here is that you take "backlog" to mean, "every issue we've identified and not fixed", whereas the PO takes "backlog" to mean "todo list that I actually have to think about". Those are both worth having, but one is a filtered view of the other. Feel free to argue with your PO which of those two things deserves the name "backlog" in a well-regulated Scrum methodology. But that might be one for the pub rather than work time.
If you move this junk out of sight and the PO still objects to it, then it's possible that there's some political reason for rigging some "code healthiness" metric. Then maybe you actually need to drill into whether it's right or wrong to include this stuff in that metric. Beware Goodhart's law: "When a measure becomes a target, it ceases to be a good measure" (or, "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes"). Especially beware that knowing the law does not make your own KPIs immune to it. This is why you don't pay bonuses for increased velocity (and if you do, what you get is ticket point inflation). You shouldn't pay bonuses for hiding bugs, either.