That's not really fair in the day and age of Electron apps. If the Electron app downloads JS code to run in its embedded browser / NodeJS runtime, then it's subject to similar attacks. Hypothetically, so too could any traditional desktop binary download and execute code. An audit will only reveal that such capability exists, not whether or not it is being abused.
If that's genuinely part of your threat model, then you simply must run on-premises code only, backed up by robust network controls that allowlist very specific parts of the Internet.
Correct. I do not think applications with such a vulnerability should ever be used or marketed as "end-to-end encrypted", since that implies a promise that a malicious or suborned vendor could not be compromise your communications—which, in the case of remotely loaded code, is misleading. I think this is table stakes for any e2ee communication app (e.g. Signal can do this easily since Apple and Google and many third-parties audit their code) but if it conflicts with your current app design, you should be realistic about whether a true e2ee-required threat model can be accommodated by your app.
If that's genuinely part of your threat model, then you simply must run on-premises code only, backed up by robust network controls that allowlist very specific parts of the Internet.