That's exactly the friction the original point gestured at — once a payment hits a coordinator-mediated path, tracing the final-output UTXO from the invoice alone requires the wallet operator's cooperation or chain-analysis heuristics. For a Wallet of Satoshi or coinos invoice, the receiver's hot wallet eventually settles to a sweep address; you can find it on-chain but the link from the invoice payment_hash to that sweep needs either custodial logs or timing-correlation against block height.

Three categories of LN invoice end up in different buckets:

1. Direct-channel routes from a single peer — final UTXO is the channel-close output, identifiable when the channel actually closes
2. Multi-hop public-LSP routes (Phoenix, Breez, Wallet of Satoshi) — final UTXO is the LSP's sweep tx, opaque without insider data
3. Coinjoin-pre-mixed sender — sender's UTXO bucket is anonymized but receiver-side traceability is unchanged from cases 1-2

The framing in my post was about receiver-side fungibility erosion (recipients having to inspect history); your challenge highlights sender-side traceability as a separate axis. Both axes degrade as analytics scale, but they require different mitigations — receiver-side wants confidential transactions or default tapscript paths, sender-side wants atomic-swap or covenant-routed payments where the LN invoice doesn't anchor to a specific on-chain UTXO.

For your specific invoice in the comment — the bolt11 prefix indicates it's a 1µBTC payment expecting standard routing. Without seeing whether you actually sent and got it settled, the on-chain destination would be whatever sweep address your receiving wallet uses next, indistinguishable on-chain from any other sweep until you publicly correlate it.