The OP seems to be the sender of the transaction from his post I read and that doesn’t put him in the position of doing CPFP, as it is only the recipient with the unconfirmed child can be able to do a CPFP.
If the stuck transaction has a change output that usually goes back into sender's own wallet, the sender can also make a CPFP with this unconfirmed change output. It doesn't matter if you're sender or recipient of a transaction. What matters is if you can control any of the stuck transaction's outputs to perform CPFP.
But we don't need to talk about CPFP because
OP actually doesn't want the stuck transaction to be confirmed. He made a second transaction paying the same recipient and this transaction was already confirmed. Therefore he'd rather want the stuck transaction to become purged/forgotten/totally replaced.
The only option is to do a RBF which will be easier if it was opt in from the initial broadcast of the transaction, but it doesn’t look like it was.
How do you come to the assumption that OP's transaction doesn't have RBF enabled? I don't think OP gave any details about it, but I could've missed something.
There might be enough nodes that already have Full-RBF enabled and from where you broadcast a replacement transaction it needs to be connected to such Full-RBF nodes otherwise your broadcast will be dropped.
