Bitcoin core will only change the master key if you encrypt a non-encrypted wallet.
It wont if you've just changed the passphrase.

Does your Bitcoin core's wallet.dat contains the prv keys of your funded addresses in Electrum?
If you have imported random keys from Electrum, then it shouldn't work unless you're lucky to pick the right ones.
If those funded addresses' keys are the ones affected by the corruption, then there's nothing else you can do with that corrupted wallet file.

The other option is to look for the original wallet.dat from Bitcoin core where those prv keys were extracted from, you can import that back to Bitcoin core instead.
Aside from that, I'm out of ideas.

Yes, but not all types of addresses created using vanity address generators.
It's exclusive to SegWit addresses generated from an "Uncompressed Public key".

And yes, now, you cannot import 'uncompressed WIF prv key' as SegWit to Electrum.

Seems like you're not the only one who's getting that "Key Error" message;
This "send Crash Report" issue suspiciously looks like the same as yours: https://github.com/spesmilo/electrum/issues/6394

---

Try to find the private key from the wallet file itself, but that requires you to unencrypt the wallet.

First, disconnect from the internet or use an air-gap machine (do not share any "private" info):

• 1. Remove the password of your wallet in 'Wallet->Password' type your password and leave the new/confirm password fields empty.
• 2. Then find your wallet file in the Electrum data directory/wallets (or where your wallet is stored), and open it using a text editor.
• 3. Lastly, find "keystore" and below it, there should be "keypairs" where you can find the address after its private key.

If you found seed and master keys along with your imported addresses, there's really something wrong with your wallet file.

Have you also considered post #5?

That issue was brought by both old versions of Electrum and whatever Vanity address generator they've used must be because of lack of research for SegWit or lack of public info or both.

For Electrum: the older version like v3.3.6 (When SegWit was kinda new), allows the user to create an imported wallet
using an 'uncompressed WIF private key' as SegWit P2WPKH (starts with bc1) or P2WPKH-P2SH (starts with 3).
Reference: https://www.reddit.com/r/Electrum/comments/bec22p/potential_loss_of_funds_if_import_uncompressed/
That's fixed (removed) in the later versions.

For the vanity address generator: There was an option to create SegWit addresses using uncompressed public key flag as stated by others.

To answer your question, transactions created using those SegWit addresses are "non-standard" which means it will be rejected by most nodes when you try to broadcast it.
The only way to spend the funds from them is to send the 'Signed RAW Transaction' directly to a solo miner/pool and ask them to include it in a block.
Here's an example of how "hard" it is to spend them: https://bitcointalk.org/index.php?topic=5192454.0

I can't replicate this, I've done the same exact steps, same settings, same OS and no exclamation point.
The difference is I'm running from source, but the official v.4.0.2 release not a development version.

The 'to be sent' amount to the recipient address changes every-time I edit the fee (manually or through the slider)

Here's what it looks like at 6 sat/B:

In case you don't have a magnifying lens: The last few satoshi digits of the amount is: 398104

When I edit it to 1.1 sat/B; there's no additional change address or rather receiving address (because yours is green):

The last few digits is: 399652

Have you resolved the issue?
Because the "spend from" address's balance was already spent: 36FpaSVB6WdZmwk4KRqH3FVv2rHV1QAhM6

That will be rejected by most nodes anyways; 1sat/B on the other hand can be easily CPFP~ed by the receiver (intentional or not by using higher fee).
That's unless the attacker's low-fee unconfirmed parent's size is too high, it'll be expensive to CPFP.

It's worth mentioning that the past "phishing message vulnerability" wasn't connected to the update notification setting.
It was the server-side error message that's disguised as an urgent upgrade notice (which will return with a generic message in the non-vulnerable versions).

That setting however was introduced after that vulnerability and as far as I know, based from the code: it's safe.

Most of the time (based on my experience), your transactions through the GUI wont be broadcast to your own mempool.
That said, you need to use sendrawtransaction "RAW_TX" first before using generatetoaddress.

To get the RAW transaction in Qt, you can right click the transaction in the "Transactions" tab and select "Copy raw transaction".

I sometimes get that error while closing Electrum, and AFAIK it's quite common in Windows.

For your transaction(s), don't worry about them, it's broadcasted in the network via the server where you're connected to
and the network will do the rest, your Electrum is just a client to "view what's happening" aside from create, sign, broadcast transactions.

This sounds like Electrum is including your wallet's "local transactions" in your new transaction's inputs.

This again looks like you've created a transaction using a local transaction as an input then the server returned that error because it's rejected by its node.
I might be rejected because the input was already spent by another transaction or it's just invalid.

Do the icons of those "unconfirmed transactions" looks like "three white gears" or a "computer monitor"?
Because I've been using freeze and coin control function of v3.3.8 and I never found any issue with it.

I think 64 halvings is the fault which rounded-up the result or you should find a way to increase the maximum decimal places of the result.
Change:
Into:
34 is enough for it to result with 20999999.998778, IDK why 34, even here: https://en.bitcoin.it/wiki/Controlled_supply.
The reward is 0BTC for the 33rd halving (34th reward era), though the maximum should be 64.

BTW, there were and there will be "destroyed coins" that will reduce that amount some more.
I'm not talking about burned coins that're sitting in blackhole addresses, I'm talking about those Tx fees that weren't claimed by the miners.
Read the last sentence of the overview, and its references: https://en.bitcoin.it/wiki/Miner_fees#Overview

You can import this to Bitcoin core using:
Where the last "true" indicates that the first value is a P2SH script.
It will produce the same address: 33CGouuJW2G66mDaQ13pMBDuztW9eLKiKw.

But it wont let you spend from it through the GUI though 

You might also need to specify your machine's specs, ISP info and 'bitcoin.conf' settings in order to find the bottleneck.

For the main question, of course it does, not only because of validation [1] but also because of the raw block size.
Remember that it's being downloaded from your peers and partially-filled/empty blocks are smaller in size.
If your CPU is fast enough, you wont even know the difference without checking the resource monitor.

[1] Your node doesn't actually validate the signatures from older "assumedvalid" blocks.
Ref1: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
Ref2: https://github.com/bitcoin/bitcoin/commit/812714f#diff-ef76fd6674f07db88c3422fdbf0bcf9fR79-R99

Maybe because some of the updates are trivial for some android phone users.

The merged PR here that were 9days-old and earlier were the updates included in the latest version 4.0.2 (from v4.0.1):
https://github.com/spesmilo/electrum/pulls?q=is%3Apr+is%3Aclosed
The first 6 in the list, specially the "back button" issue, which I didn't experienced.

The minimum for Electrum is 0.002BTC plus fee.

For the backup, you need to enable it first in the 'Menu->Settings->Backups: No -> Yes'.
Or you haven't granted Electrum a "file management/storage permission" yet.

It could be their pool's log-in page: https://console.pool.bitcoin.com/login
In that's the case, I can access the page without issue; it's also online when tested with "isdown" online tools.

He most likely restored or backed-up a different seed phrase.
Also, the Android version <v3.3.8 didn't have an option to restore BIP39 seed, and OP mentioned that he didn't updated it.

@mumbleman It's best if you send the funds to a new wallet with a seed that you're 100% sure that will restore the same wallet.

I'm using v4.0.2 arm-v8-64bit and there's an "Enable LN" button below the wallet information (third button)...
It's just grayed out since my watch-only wallet is P2SH-SegWit.

It's not in those screenshots, he needs to tap the wallet name above (upper-left) to display the 'wallet information'.

2BTC missing is definitely not a fee issue, because the maximum standard transaction size at 10 sat/B wont reach that amount.

Can you remember the actual balance of that wallet since the last transaction that you've made?
'Coz there has been a lot of reported bugs in Blockchain's balance lately (in Web Wallets child-board), mostly displaying previous balances.
And FYI, they haven't yet received any replies to their tickets.

I second the "export solution", you just need to know that if you have more than one wallet in blockchain.com,
you'll have to create more than one wallet with different derivation path for the '2nd-3rd-more' accounts.