Duo 2FA works the same way. In principle yes. And it's basically always accompanied by a "click this link" -> "are you trying to log in, and is this you? yes/no" page to resist that.

Small code copying is also a very good answer though, yes. Roughly as easily manipulated, but nothing's perfect, and it's less "I didn't mean to click that button"-prone.

That’s why you combine it with a check for source IP and tell your user that they need to approve from a device that has same IP as the one they are logging in on. So if I’m logging in on my laptop, and approving with my phone, it will be rejected if my phone is using mobile data while my laptop is using landline, but will approve if my phone is connected to WiFi of the same network my laptop is connected to, or if my laptop is tethered via my phone, because then I have same external source IP on both devices.

The links are one-time use so you need to take this into account anyway or users simply can't login. It's usually done with a required button click after following the magic link. Or you can try JavaScript techniques to detect a real browser.

When I sign on to a bank it sends an SMS. Then my phone prompts me to share that code with the brower, on my desktop. It's a neat QOL "feature" - but kinda feels too automated to be secure.

I've come across dozens.

Google does it. Paypal does it. Duo does it. Lots of single-sign-on systems do it. All of those including not-TV scenarios, just normal computer-and-phone stuff, as well as sometimes other weird flows. Many of these are far beyond what most would label as "security competent", into "login security is a large part of their business and they have significant numbers of specialists hired".

(it is probably safe to say none are "truly secure" or "actually security obsessed", but I doubt that's actually possible in large quantities. the requirements are too steep, for both implementers and users.)

It's not the most common, certainly, nor anywhere close. But it's very far from nonexistent.