Equating technical debt to bad code does seem fairly common, but I think that that stems from what people think of as bad code. I feel that technical debt is commonly references in connection to writing some quick and dirty code that solves the immediate problem with little regard for the future. Code that is quick and dirty may feel like bad code, but it doesn't have to be. If your fix is good code though, doesn't that kinda mean that it's not quick and dirty and that it doesn't add any technical debt to a project?
Architectural decisions may very well result in technical debt, but an architectural decision to go with a vertically scaling solution doesn't have to be a bad decision or bad code. It's only really a problem once you get enough users that you need to start scaling horizontally. At that point though it would very much be considered a technical debt since it was originally trading development time with future scalability.
Technical debt is the difference between the actual code and how you would ideally write it with today’s knowledge and no time constraints. By that definition, bad code is a subset of technical debt, as you presumably wouldn’t write that bad code today unless maybe under time pressure. The other kind of technical debt is when you have in principle good code but the assumptions, requirements or external conditions have changed, and thus you wouldn’t write it that way today. Your second paragraph matches that case.
Architectural decisions may very well result in technical debt, but an architectural decision to go with a vertically scaling solution doesn't have to be a bad decision or bad code. It's only really a problem once you get enough users that you need to start scaling horizontally. At that point though it would very much be considered a technical debt since it was originally trading development time with future scalability.