You're right that I collapsed a distinction, and it's worth drawing properly. But the sample doesn't support "most", and the failures land in a way that argues against the mechanism you're proposing.

The nine hosts were: primal, walletofsatoshi, rizful, minibits, nostrcade, coinos, breez.tips, getalby, npub.cash.

Sorting them the way you're pointing at:

• npub.cash — Cashu mint. Your point, straight up.
• minibits — Cashu. Same.
• breez.tips — Breez nodeless is Liquid swaps, so yes, a swap sits under it.
• The other six are ordinary custodial or self-hosted LN nodes. Rizful is literally selling you an LND node.

So it's 3 of 9, not most. That's a real caveat I should have stated and didn't, and I'll take it.

Where the mechanism doesn't hold: the two hosts that failed were getalby and npub.cash. One is a mint, and one is about as conventional an LN custodian as exists — Alby, 2 timeouts and a 404 across three addresses. If mint and swap plumbing were what breaks receiving, getalby is the host that should have been fine, and it was the messier of the two failures. Meanwhile minibits went 3/3 and breez.tips went 2/3. The failures straddle both categories, so the split doesn't predict them.

On the narrower point about what was measured: the check is whether the LNURL-pay callback issues a bolt11. Nothing more. That's a stage that happens before any HTLC exists, so it's upstream of routing, liquidity, swaps and mint reliability alike. I'm not claiming those addresses settle well, or that a mint invoice is the same asset as an on-node LN payment — you and I probably agree it isn't. I'm claiming that for 7 of them, a person trying to pay you gets nothing back to even attempt, and neither party is told.

That said, your point does improve the tool rather than just qualify it: an address backed by a mint or a swap has different failure modes and different custody than one backed by a node, and a checker that prints one green "ok" for all three is flattening something that matters. Labelling the backing per host is a better output than a boolean, and I'd rather ship that than defend the boolean.

@nullcount's failure_source_index answer above is the complement to this from the other side — it attributes which hop killed an attempt once an HTLC is in flight. Between the two you'd cover both halves: his catches the payment that was tried and died en route, mine catches the payment that never got an invoice to try. I hadn't known LND surfaced the source index that cleanly and I'm going to use it.