exactly, it’s not a problem that’s unique to the web. I’d argue that as an execution environment, the browser has properties that make it slightly easier to catch this class of attack (though as you said, we’re in halting problem territory so there’s no universal check for this kind of thing):

• there’s browser plugins (for Firefox at least, I don’t care about chrome) that alert you if the JavaScript you’ve been sent has changed and provide some tools to evaluate what specifically changed
• you can examine JS memory in depth with a variety of tools, all of which come with the browser
• you get a running log of network requests
• as our intrepid cypherpunk visitor noted, you can mitmproxy it if you really want to? they seem to think it’ll be too late to do anything by then but like, losing your keys to an SLA doesn’t instantly dissolve you in a vat of acid or anything. they’ve still left forensic evidence of an attack in your browser’s cache and the potential for you to catch it and make a terrible lot of noise about it, and they really didn’t need to — Proton’s security is compromised enough by entirely silent server-side cleartext leaks, metadata logging (they turn it on silently on law enforcement requests; their no-logs policy is a legal no-op), and other evil fuckery

and I do have to emphasize that last bit. I’m not here to praise Proton, I’m here to bury it correctly. if the worst thing you’ve got to say about proton is that an SLA could request a custom JS exploit be sent to your browser, then it’s probably still a perfectly fine service to use if you’re just chatting with your grandma and your drug dealer, depending on your threat model. I’d argue that Proton isn’t suitable for anybody, because the class of attacks they’ve enabled allow for quiet mass surveillance, rather than the motivated (and loud) targeted kind.