Nodes with default mempool size already dropped it, your wallet's backend server must have dropped it as well.
But that doesn't mean that it'll stay that way since other nodes still have it, most blockexplorers' nodes for example.

Since it's not showing in your wallet, you'll have to import your seed phrase to another wallet that enables you to pick a server with larger mempool size setting.

The most suggested is Electrum (electrum.org), you can import it by ticking "BIP39 seed" option and selecting the correct address type.
From there, you can manually select servers (instructions) until your transaction appear as "unconfirmed".
To do CPFP, right click on it and select "Child Pays for Parent", set the child's fee (refer to the "Total feerate" below for the effective fee rate);
In the next screen, review the transaction and click "Sign", then "Broadcast".

You mean the parent transaction with 500 inputs?
All of those inputs are confirmed so the problem is just its size (33918 vB + its children) which requires a lot of fee to set a good fee rate.

Don't overthink it; with or without locktime, it wont get confirmed if the parent is still unconfirmed.
Some wallets or services usually uses locktime with the current tip (block height) of the blockchain.
Also, those CPFP transactions don't look intentional but rather other priority transactions sent to others. (the sender must be using a custodial service)
It's just the change of the previous transaction was used to send to the next which is the usual.

It must be automated if it's also from an exchange or custodial wallet.

The large parent transaction was broadcasted 2 months ago (according to mempool.space) when the average fee rate is lower than 10sat/vB,
it's a pattern of a consolidation transaction of an exchange or custodial wallet that even used a medium priority fee at that time.
But they didn't expected the sudden surge in transaction fee and unfortunately, they didn't took action to bump/accelerate it before the fees reach to what it is now.

For the record, since the first parent transaction is beyond the bottom of the default mempool size, all of its children transaction including it should be dropped from majority of mempools.
I can't find your transaction in my node's mempool as well.

However, given that it's still included in some blockexplorers and nodes with high mempool size setting, it will still propagate in the right conditions.
So yeah, there's no cheaper solution but to wait.

In that case, you should put your bitcoin.conf file inside bitcoin's default data directory, put the datadir for mainnet and testnet in that file and remove the conf files from the separate custom datadirs.
In MacOS, it should be in: ~/Library/Application Support/Bitcoin/bitcoin.conf
That way, bitcoind will automatically load it without needing you to specify the paths. (the GUI will still use the one set in the Welcome Screen though)

Or set the --datadir in the command line arg for testnet and mainnet and remove the --conf and --walletdir args.
Then put a bitcoin.conf file for testnet (still with [test]) and mainnet in those separate datadirs.

In both cases, you do not need to set blocksdir, walletsdir, settings lines in your bitcoin.conf file or command line.
Because those aren't necessary if you intended to save the settings.json, blocks folder, wallets folder inside the custom datadir which is already done by default.

---

Also, you may consider fixing the paths in testnet (if it's not intentional) because-
in testnet, it'll automatically create "testnet3" directory in the specified 'blocksdir' and 'datadir'.

For example:
These configurations will result with this folder structure:
Folder where the datadir will be saved: "......./Bitcoin/testnet3/testnet3"
Folder where the blk and rev files will be stored: "......./Bitcoin/testnet3/blocks/testnet3/blocks"

If the intention is to save the block in the testnet3 directory and the datadir is set, you can remove it from the config/args.
Lastly, if the datadir is to be set in "......./Bitcoin/testnet3", the datadir for testnet should be: datadir=/Volumes/Crucial\ X8/bitcoin/Bitcoin

That is only possible in "custodial wallets" where your balance is held in their database rather than the blockchain.
So when sending, it'll show that it's sent from their hot wallet's address instead of your deposit address.

But that's not the case in non-custodial wallets like Electrum since Bitcoin uses "UTXO model".
Let's say that you received a transaction: in mempools (unconfirmed) or blockchain, it's saved as a new "Unspent Transaction Output" (UTXO)
which is locked with a script that can be encoded and display by your wallet as an address.
To spend it (when sending), your wallet has to refer to that specific UTXO as an input, not any other unused locking script that haven't received any bitcoins yet.
Since that specific UTXO is used as input, it'll show in blockexplorers and wallets that it's sent from its address-encoded script.

So TL;DR, using an unused address to send not possible.
That's not categorized as "address-reuse" if the address isn't used to 'receive then send' more than once.

Only the earliest transaction is possible since the next txn is a child of it and the last is the child of the previous one.
They wont accept transactions with unconfirmed parent.
Let's juts hope that its size isn't higher than their free accelerator's maximum allowed size.

But this reply mean that OP must have already set about 40000sat fee to the first transaction (must be confirmed by now if so) or last transaction:

The "Config file arg" lines for testnet should be listed as "Config file arg: [test]" instead.
Those are most likely for your mainnet configurations set somewhere else which will show regardless of the chain you indicated in the command line.

Since your bitcoin.conf file isn't in the default data directory, specify its absolute path in --conf command line option.

Definitely a bug in Blockchair's Blockexplorer.

Notice that the TXID are the same? It means that its the same transaction.
In the blockchain, the chance of two different transactions to produce the same TXID is 2^256 (nearly impossible to happen) which is also a collision in SHA256.
Since the two transaction's TXID are the same, it means that Blockchair blockexplorer just had it duplicated due to a bug in their database or some sort.

Your full node has a corrupted UTXO Set (chainstate), you'll have to start it with --reindex-chainstate to fix that.
It wont redownload the blockchain since it's not set to prune but it may take a quite while depending on the hardware. (but it's faster than -reindex)

FYI, most of the time, it's caused by "unsafe" shutdown of either Bitcoin Core or the PC.
So be sure to close it the right way, if it's frozen, wait for it to respond or use bitcoin-cli stop to shut it down.
Bitcoin Core usually freezes while syncing specially when the data directory is stored in a slow hard drive,
but even if it's frozen, it's working in the background so don't force-close it while it's frozen.

If it's about Monero, I doubt people here in Electrum board would be willing to give you answers since it's off-topic.
If you want, you can post a new topic in 'Altcoins' or 'Wallet Software' board regarding that matter.

As for sending or receiving cryptocurrencies in Android or iOS in general, there are a lot of SPV or centralized wallets out there that works in either platform.

I just found out that OP also posted this in Electrum's GitHub repo as a new issue which is closed without getting any sufficient answer.
Link: https://github.com/spesmilo/electrum/issues/8751

I'm uncertain on this answer so I only answered one question in my previous reply (CMIIAW):
Electrum's lightning wallet requires a master private key where the private keys to be used in your lightning transactions' HTLC (Hashed Timelock Contract).
It can't rely on imported keys since it'll eventually run out of available unused keys after few transactions and reusing those isn't an option because it's unsafe to reuse used keys in old HTLC.

That video if for the older Electrum binaries that are signed by ThomasV alone.
The latest now have 3 signatures. Namely; by ThomasV, SomberNight and Stephan Oste (Emzy).

The result that you get is "good enough" for having one valid signature and certified certificate out of the three.
But if you really want a "green result" you should redo the steps to "import" and "certify" the other two developer's PGP key.
You can find their keys here: https://github.com/spesmilo/electrum/tree/master/pubkeys

That would be for your own PGP/GPG key pair, you can leave the email field empty if you want.
For verifying Electrum signatures, it doesn't matter if you've set an email or not.

It's never been a requirement but optional for the users' own safety.

AFAIK, there's no Electrum in the 'App Store', if there's one, it isn't official.
For Electrum downloaded from Android's PlayStore, you should check if it's uploaded by "Electrum Technologies GmbH" since you can't verify an already installed app.
If you want to verify, download the ".apk" and its signature file from electrum.org to verify it in your PC before installing to your device.

Okay as said above, its inputs are already spent.
Your wallet probably able to make and broadcast such transaction because it failed to scan the transaction that spent it.

Using rescanblockchain command (instructions) should update your balance to reflect the correct transactions and available UTXO to spend. (since those're spent, those shouldn't be available)
But if your node is pruned, you wouldn't be able to rescan the whole blockchain but only from the lowest block height that your node has.
After the rescan, it should be dropped from your mempool.

Have you set any configurations related to transaction relay or mempool in your bitcoin.conf file, GUI settings or command line options?
Because it may be broadcasted exclusively to your node due to a setting that allows it (thus the "in mempool" note) but rejected by all your peers for some reason.

Since you already willing to share the transaction via txid which we can't find, it's better if you can share the raw transaction for us to see the actual issue.
Get it from the 'Transaction' tab of the GUI, right-click on it and select "Copy raw transaction" or via getrawtransaction command.
Then put it inside [code][/code] tags so the forum wont mess its format.

In case that you want to abandon it as suggested by others, you'll have to get it out of your mempool first before the "abandon transaction" option can be clicked.
One way is to remove the option that allows it to your mempool which is at the same time allowing you to create transactions that'll have trouble with propagation.
Or the manual removal of mempool.dat (Bitcoin Core must not be running) and temporarily setting walletbroadcast=0 to be able to abandon it.

Yes, that is why I need clarification in that matter.
To see if that weird transaction is actually targeting a bug or just a user playing with rbf.

Mine is just a guess, we can't jump to conclusions because of one wild guess.

You mentioned that it's a "clear pattern", are there a lot of transactions that has that same behavior?

Interesting...
I'm not too familiar in Bitcoin Core's fee estimation algorithm but my initial guess is it's trying to trick the fee estimation by continuously broadcasting high fee replacement transactions with enough delay for the previous transaction to propagate.
Since it's a replacement, each relayed replacement is cheap since it'll only need to add a few satoshi on top of the transaction that it replaced.

But I'm not sure if the fee of the replaced transactions that a node relayed wont be removed from its "bucket" and if those will still be counted to its fee estimation after the last replacement is confirmed though.
If it is, that could be the purpose of those rbf spam.

It used to be possible in the older version but the devs decided to disallow it in v2.0.
Refer to this commit: https://github.com/spesmilo/electrum/commit/4ce699bf2570a4478c1f467f676c46e42f63f2b4

That's probably because it breaks the purpose of the seed phrase backup since the imported keys wont be recoverable from it.
And managing the HD derived keys and the imported keys was a mess.

No problem,
I'd like to also add that there's a chance that the original wallet isn't actually corrupted and the corruption of the restored "bluebird" wallet was just a result of the sudden crash.

If that's the case, you can try to Install Bitcoin Core on a separate "air-gap" PC and restore and load a copy of the original wallet.dat file there.
The wallet isn't actually corrupted if it loads, then you can export its private keys from dumpwallet command
or if it's a descriptor wallet, export its master private key via listdescriptors true

You may also want to consider restoring just the addresses or extended public key (xpub) to Electrum to create a watching-only wallet.
From there, you can create transactions that you can import to the offline Bitcoin Core to sign with your private keys.
Then the signed finalized transaction can be exported back to Electrum to broadcast.
It's a cold-storage setup which is safer than loading (and unlocking) the wallet.dat file on an online PC.

Wallet export or Wallet information?

Wallet export isn't available in Android at the moment,
Wallet information is still accessible in both Desktop and Android versions.

But if it's tracking that you want, you only need the master (extended) public key from the wallet information.
To get to wallet info in Android version: Click the wallet name above then select "Wallet details".
Your master public key should be listed there unless you're using an 'imported wallet'.