3 isn't really possible, because the redirect needs to take you back to the browser session where you initiated the login from.
Have your logging-in session wait for / poll "has visited magic link", and authenticate that session when it's done.
Tons of systems do this. It works great, and it can quite easily work without any web browser at all on the logging-in side because it just needs to curl something -> poll for completion and save the cookies -> curl against the API. A number of oauth flows for e.g. TVs work this way, for instance, because it's a heck of a lot easier than integrating a full browser in the [embedded thing]. Many app-based 2FA (e.g. Duo) works this way too.
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.
I don't mean to imply that just visiting the link should be enough to complete a login. That's a GET and there's a LOT of issues with doing anything important on GET. Just "do something on a different machine, then automatically complete login on the one logging in", and magic links to trigger that flow are a rather straightforward option.
There's no reason at all that it has to all occur on the same machine, and many reasons why attempting to require that doesn't work out in practice even when it does happen on the same machine.
TVs etc. are special cases because obviously there is no way to redirect to them, and even there developers will always have some kind of secondary checks like having you enter a code displayed on the screen.
But somehow, the desktop browser and my mobile are tied together for this app. But no other sites have this magic.
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.
1. Attacker starts a log in and triggers a magic link email 2. Email received and my browser client previews the link without my desire 3. Attacker is now logged in
This works on 99% of magic links I've tried except for cases when they are trying to prevent account sharing. I remember the Bird bike app did this, where they required the magic link to be clicked on the same device login was initiated on. I was using my friends account and he would just forward me the link until one day this stopped working.
I feel the way Netflix did this broke the social contract of profile sharing on purpose - before, if you were a good tenant, you could freeload off another paid account without inconveniencing them at all. Memes and jokes formed of still being on an ex-partner's account or how people would rename themselves "Settings".
Getting an email and being harassed for the code by all those account sharers? Much more open and open for annoyingness.
I assume it generates a session on the post-login screen and authorize that session upon accessing link
People blindly click links all the time. It would have a low success rate, but would be more than 0%.