Electrum lacks a clear way to handle dust attacks

Recently our hot wallet was dusted with an output from an advertisement transaction. The advertisement transaction remains in the mempool unconfirmed, assumably for a couple days before being dropped.

The hot wallet continues processing withdrawals, which are all unconfirmed on the blockchain, until finally crashing with the mempool too long error.

At this point we are in an "all hands on deck situation".

A developer loaded the hot-wallet private key into the Electrum GUI and attempted a cancellation for the transaction immediately after the dust input arrived (spending the dust input) with a very high transaction fee, almost $200 USD.

This cancelled the 20+ unconfirmed tx's, leaving just the RBF transaction. However, because the dust attack never confirms the RBF never confirms, despite the huge fee. Another RBF is attempted with a $400 USD transaction fee, but this likewise never confirms.

Unfortunately at this point it doesn't seem like Electrum has any effective way to fix the situation. Freezing inputs is only allowed for inputs which are not currently part of a transaction, so the coins tab does not show the dust inputs or otherwise allow you to freeze them.

Also, modifying with RBF doesn't allow you to drop an input, nor does Electrum GUI seem to allow a custom transaction while selecting inputs from transactions you want to replace.

What can we do in these situations to free coins that have been dusted? The ability to freeze inputs only helps you if a dust input has arrived in your wallet, not in a situation where your wallet has already attempted to spend the dust input.

Lastly, is it possible to implement functionality in Electrum to easily stop this kind of attack? For example, automatically disabling the use of dust inputs in new transactions would prevent this from happening.

Thanks

Start by tracing Electrum's dust-input handling across coin selection, transaction creation, input freezing, and RBF replacement, using the described unconfirmed mempool scenario as the reproduction case. Done should define an effective way to prevent or recover from dust attacks and cover the behavior with tests, but the issue does not name specific files or existing test entry points.