Either close bitcoind first and start it with that -connect command line option...

Or use addnode RPC, use bitcoin-cli instead of bitcoind to use the command:

But take note that addnode works differently than connect,
connect will exclusively use the selected node(s) while addnode will still enable your node to connect to other peers.

The message will appear regardless if the command used is a wallet rpc or not, if you're using the GUI.
That's just a note to mention which wallet is selected in the drop-down menu above it.
But will only appear once until another wallet is selected.

If "(none)" is selected, it will say "Executing command without any wallet" instead.

Reference code: github.com/bitcoin/bitcoin/blob/master/src/qt/rpcconsole.cpp#L1031-L1038

---

To see if a command is actually wallet-specific, enter help in the console;
Those under == Wallet == are the commands that affects only the selected wallet.

Any update to your search for the address' origin?

You should also verify the binary/installer of your currently installed Electrum and see if the signature matches.
Follow this tutorial: bitcoinelectrum.com/how-to-verify-your-electrum-download/ (download only the signature file of the Electrum variant that you have)
If it passed, then you can rule-out the possibility that you have a fake Electrum.

It's only available for descriptor wallets so you can't export individual private keys with dumpprivkey command.
But you can export its parent descriptor containing the master private key using listdescriptors true

The latest Electrum versions only generates Native SegWit electrum seed by default, that includes the format of the master keys.
For example, the master public key that you're getting starts with "Zpub" intead of "xpub".

There's a workaround to convert the Zpub key but there must be a way indicate that the HD MultiSig wallet that you'll create in Green/Bitpay is Native SegWit.
To convert the Zpub key, go to "Console" tab (View-Show Console), then type:
Replace "ZprvAWgYBB.....wCND7HYcZr" with your master public key.

However, Bitpay is using an exclusive "Invitation Code" instead of xpub so it may not work.
Green on the other hand, doesn't have such option only their "MultiSig Shield" or it's only available in the IOS version which I do not have.

Now, in Bitcoin Core version 23.0, it's as easy as selecting "Bech32m (Taproot)" in send tab's drop-down menu.
That's if the wallet is a "descriptor wallet" and created with v23.0, otherwise the user has to manually import p2tr descriptor to their older descriptor wallets.

Take note that you can create multiple wallet files in Electrum, it's not limited to one.
The seed phrase may be correct and will restore your first wallet, but you may have been using a different wallet when you copied an address to receive your bought bitcoins.

Also, even if it's sent to another wallet, the coin shouldn't be moved by itself otherwise, someone owns the key of that address.
If not clipboard malware, I suspect that it may be a watching-only imported Electrum wallet that you previously created with address that you've copied somewhere.
Your answer alone is enough to tell that it doesn't belong to your wallet.

The question is: who owns that address?
Review some chat/email/conversation to see if it's from someone you know (maybe someone you've sent bitcoin before, a contact or an exchange deposit address).

I think he's presuming that there could be a centralized service or exchange that have a broken implementation of HD wallet which produces the child keys in series instead of the standard implementation.

In fact, all of the addresses he presented belong to a single wallet according to walletexplorer: walletexplorer.com/wallet/00113e9c26df0947/addresses
Having a total of 6,023 linked addresses suggests that it's indeed an exchange or service provider.

That's the response if that command is executed successfully.
Otherwise, it'll return with "Block not found", "blockhash must be of length 64" or other errors.

You can immediately see that the block is invalidated in bitcoind with the lines InvalidChainFound: invalid block=n or in the logs (debug.log) file.

To be fair, if your friend is innocent, he will indeed see 0.004BTC incoming to his Electrum wallet from his perspective.
However, if the "hacker" sent 0.004 to your friend to trick that he have received short amount.
That hacker should at least know your deal's situation because otherwise, no hacker would send some of his "income" to the intended receiver.

For now, check your previous conversation to know who's to blame regarding the missing funds.
If the address bc1qcj3f0kllhwctsvgud4k9zv5gxqf574fm2qlj5t was given by him, then it's his fault.
If he's given you the address bc1qfg0a4ns3z4ud2d90t8hfgc2a2x6j65y7j3rnsa instead, it's your fault.

---

And I've also read the replies in the Reddit thread.
Take note that even if blockexplorers say that it's "change address" it doesn't mean that it's true because the tag is only based from guesswork.
For example, in the txn between the two addresses in the OP, the sent amount is 0.004 which is a "round amount" while the other received 0.01005506 which is an "exact amount".
Most blockexplorers will tag the one that received the exact amount as the change because wallets usually send the change up to the last satoshi while the receiver usually receives round amount.

You can't get it from that transaction.
You can get it from this transaction: blockstream.info/tx/ed9ed571d9213cb62f019e0e8d93ab3854c97237512797f9b3bef41ec378bced?output:22 which is what that outpoint is referring to.

You or your wallet should already know that hash in order to "add it to the structure", you can't get it from the transaction being built
For example, you can get a txid from your wallet's inbound transactions which you can also get with listunspent RPC, then use the txid of the one you want to spend as the outpoint.

I also followed-up a question to that because I don't know if OP's friend is the poster of a Reddit thread with the same title (link),
Because for some reason, this topic has "friend" as the receiver while the original Reddit thread is all first person.

It's already in json format so the transaction's txid should be already available.
In that specific case, it's the line that I left in the code snippet, it's the same as the one in my example.

Now I saw where the confusion is.
The "hash" ed9ed571d9213cb62f019e0e8d93ab3854c97237512797f9b3bef41ec378bced is the txid of the input of that example transaction.
You can't get that hash from that transaction's sha256d result, it's only referencing that txid (& vout) to find the UTXO that it's trying to spend.

What we want to get is the hash 4aca2e7e393b04e6b9dfbafd8bc2605c5547c49bb7de55029b76da8f884a4306 in order to spend the example output.
Like here, where it's spent: blockstream.info/tx/13fb6a1f56cd383ecbf90fd5b9463553f2fa4cacff34eb5ba99d991e4f74f6c4
As you can see, the first input is referencing 4aca2e7e393b04e6b9dfbafd8bc2605c5547c49bb7de55029b76da8f884a4306 (vout: 0).

My best guess is, the address bc1qcj3f0kllhwctsvgud4k9zv5gxqf574fm2qlj5t is from an imported wallet.
The key point is the transaction that spent one of your deposit returns the 'change' to the same address which is the default behavior of imported wallets.
The receiver bc1qfg0a4ns3z4ud2d90t8hfgc2a2x6j65y7j3rnsa which belongs to your friend's wallet however, looks like from a standard wallet based from its txn history.
Also, the two addresses couldn't be from the same wallet because the last transaction wouldn't make sense (otherwise, sent to the same wallet).

Some things he can try:

Maybe he has two or more wallet files?
And forgot that he received it to the other wallet and sent 0.004 to the other.
He can check it in the menu: "File->Open".

He can try to generate more addresses and see if it'll show up:
Go to 'Console' tab ("View->Show Console" to enable), then type: [wallet.create_new_address(False) for i in range(1000)]
But as I mentioned, it might not be in the wallet where bc1qfg0a4ns3z4ud2d90t8hfgc2a2x6j65y7j3rnsa belongs.

Lastly, investigate if he's telling the truth.
Is your "friend" an acquaintance or just someone you have contact with?

Here's an example then:
Let's say you want to spend the first output of this transaction: blockstream.info/tx/4aca2e7e393b04e6b9dfbafd8bc2605c5547c49bb7de55029b76da8f884a4306
The short version is, that's the TXID that should be used in your transaction input's outpoint.

The long version is, you can get that by hashing (SHA256D) the to-be-spent RAW transaction;
for SegWit, witness data should be omitted first.
getrawtransaction 4aca2e7e393b04e6b9dfbafd8bc2605c5547c49bb7de55029b76da8f884a4306:
Without the witnesses, you'll be left with:
SHA256:                    19911b5338814ae41175533e224bfdadbe1319f78c194659baaa4ac80fbb9f91
SHA256:                    06434a888fda769b0255deb79bc447555c60c28bfdbadfb9e6043b397e2eca4a
Reverse byte order: 4aca2e7e393b04e6b9dfbafd8bc2605c5547c49bb7de55029b76da8f884a4306

A few references:

• Transaction data: learnmeabitcoin.com/technical/transaction-data
• TXID: https://learnmeabitcoin.com/technical/txid
• Witnesses: https://learnmeabitcoin.com/technical/transaction-weight

With which character does your private key starts? 6, 5, K or L?
Because the "passphrase" might be for Brainwallet, not for BIP38 private key and you might have a bare WIF prvKey all along.

If it's any of the above but "6", it not encrypted.

There's no definitive way to detect which output (not another txn) is the change.
In the blockchain, the output for the change does not differ from the actual sent amount's output.
There's no label, mark or data that will tell that it's the change.

All you can do is to "guess" based from the common characteristics of a change output.
Example: https://en.bitcoin.it/wiki/Privacy#Change_address_detection
Take note that most privacy-oriented bitcoin users rarely make those mistakes.

Or pay for services that could do blockchain analysis reliably (but still not 100% accurate).

Thanks for the clarification.

@darkv0rt3x In addition to only having the public key, (based from the above) Creating a descriptor wallet with "Disable Private Key" option will make the wallet watching-only.
In my quick test, it wont accept a descriptor with privKey.
On the other hand, a descriptor wallet with private keys enabled wont accept the example descriptor in my test since it only has a pubKey.

But the descriptor only contains the pubKey, as you can see in the getaddressinfo's result, it's the same as the pubKey.
Also, when you go to the send tab, you won't have any option to "Send" but only "Create Unsigned".

I wonder if showing that it's "iswatchonly": false, is a bug or intended.

Are you being contacted by someone who made you import that address or install the wallet?
Because that's a typical scam method: to make the victim deposit to a watching-only wallet,
then the scammer will send more funds to the wallet to increase the displayed balance in order to "encourage" the victim to deposit more.
But since it's a watching-only wallet, only the the owner of the private key (the scammer) will be able to spend those bitcoins.

It's not possible
Since if it is, anyone can just get a random address with huge funds from a blockexplorer and import it to Electrum, then turn it into 'Standard'.

If you know its private key or seed phrase of the wallet where it belongs, restore a new wallet (File->New/Restore);
And select the necessary option depending if you have a seed phrase (Standard->I already have a seed) or private key (Import bitcoin addresses or private keys).

But before using the wallet, make sure to check if you're using a legit Electrum wallet by verifying its digital signature (as well as your PC's security).
Be careful since there are a lot of fakes and IDK if the "confusion" in your post is due to using a fake wallet or really just a confusion.
Verification tutorial here: bitcoinelectrum.com/how-to-verify-your-electrum-download/