The solution is obviously to not show a notification at all, ever.
If I'm trying to log in, I know that I have to go into Authenticator and approve, so just check if there are outstanding requests (e.g. with a 2 minute timeout) when I open the app.
Except that's still a failure: the attack can script that to ensure there's always a notification. Doesn't have to get it right then and there either - they have infinite time. Might be this month, might be next month.
The user interaction of classic TOTP forms an important grounding function: it forces (in most cases) spatial locality of the user and the device being interacted with.
Some providers also give a unique identifier to each request. I always check them if it's present. Also, having multiple selections (numbers) also prevents this attack somehow. Your prompt says 7/56/9, but neither is there. So what? Or, you have the number in your prompt by chance, and it's not the right choice for that prompt.
Nevertheless, at the end of the day the buck always stops at the user. User have to be diligent and shall have no blind trust on anyone/anything.
If a hacker uses my account to hack my employer via Microsoft's terrible MFA, it's not my problem. The buck stops, as always, with the person who cares about the resource being accessed, or who is made to care by being legally liable.
For a disgruntled employee (most employees), getting hacked is a win-win.
What if it's Google, Blizzard / Epic (Battle.net), and something personal? These services use the same flows.
Or worse, what if it's your e-Government app, and you lose all your identifying information and somebody can become "you" with all the information they got?
Will you say "Meh, it's a personal account, and I gave access via MFA, but who cares, it's not my problem?".
If I'm trying to log in, I know that I have to go into Authenticator and approve, so just check if there are outstanding requests (e.g. with a 2 minute timeout) when I open the app.