Fix `is_payment_rgb` logic in `outbound_payment.rs` – avoid incorrect inbound path check for outbound payments

[free-free-6]

This PR addresses a bug introduced when refactoring HODL-related logic (based on workflow from #118 ), where outbound RGB payment validation incorrectly checks both inbound and outbound payment info paths, leading to runtime panics in specific scenarios.

🔍Reproduction Steps
Following the flow from PR #118:

1. Set up node and channels per documentation
2. Initiate an outbound RGB payment via /sendpayment
3. At step 3, the node panics with:

INFO request{uri=/sendpayment request_id=...}: rgb_lightning_node: STARTED

thread 'tokio-rt-worker' panicked at rust-lightning/lightning/src/rgb_utils/mod.rs:548:51:
valid rgb payment info: Os { code: 2, kind: NotFound, message: "No such file or directory" }

thread 'tokio-rt-worker' panicked at src/utils.rs:318:14:
called `Result::unwrap()` on an `Err` value: RecvError(())

🐛 Root Cause
In [outbound_payment.rs], the helper function is_payment_rgb currently checks both outbound and inbound payment info paths:

pub(crate) fn is_payment_rgb(ldk_data_dir: &Path, payment_hash: &PaymentHash) -> bool {
    get_rgb_payment_info_path(payment_hash, ldk_data_dir, false).exists()  // outbound
        || get_rgb_payment_info_path(payment_hash, ldk_data_dir, true).exists()  // inbound ← unnecessary here
}

For outbound payment flows, only the outbound path (false) should be validated. Including the inbound check (true) causes false negatives when inbound metadata is absent—triggering the panic above.

✅Fix

• Restrict is_payment_rgb usage in outbound contexts to check only the outbound path (false)
• Add clarifying comments to prevent future misuse

[zoedberg]

This seems a duplicate of #20. As explained there, I agree that the method is imprecise, but at the same time I would prefer to fix it only if we prove a bug. The bug you mention is possible only in the PR you proposed (RGB-Tools/rgb-lightning-node#118), which I've closed since we already have a more complete PR for HODL invoices (RGB-Tools/rgb-lightning-node#91). As already said I think we should discuss this in that PR.

[free-free-6]

@zoedberg
Thanks for pointing me to PR #91. I've reviewed the implementation and I'd like to clarify why the is_payment_rgb bug
doesn't surface there — and why it does in my use case.

PR #91 vs my scenario

PR #91 implements a basic HODL invoice with only 2 nodes. The receiver (Node2) generates the preimage itself, so
when it's time to settle, it simply calls /claimhodlinvoice → claim_funds(preimage). Node2 never calls /sendpayment
with the same hash. The is_payment_rgb() code path is never triggered.

My use case is a submarine swap / payment gateway with 3 nodes (A → B → C):

1. C creates a BTC invoice (hash=H, C holds the preimage)
2. B creates an RGB HODL invoice with the same hash H for A
3. A pays B's RGB invoice → color_commitment() creates H.inbound
4. B pays C's BTC invoice via /sendpayment (hash=H) → triggers is_payment_rgb(H)
5. is_payment_rgb finds H.inbound → incorrectly returns true → reads non-existent H.outbound → panic

The key difference: in PR #91, Node2 owns the preimage, so it never needs an outbound payment with the same hash. In
my scenario, B doesn't know the preimage — it must pay C to obtain it, causing the same hash to exist on both the
inbound and outbound sides of node B.

Why the fix is correct

is_payment_rgb() is only called from outbound_payment.rs (3 call sites, all outbound context). Checking the inbound
file was always logically wrong for outbound payments — it just never mattered before because the same hash didn't appear
on both sides of a single node until the submarine swap pattern.

Removing the || inbound check has no impact on existing functionality:

• RGB outbound payments: always have an .outbound file → still returns true
• BTC outbound payments: have no RGB files at all → still returns false
• The deleted branch was never correctly triggered in any prior scenario

[zoedberg]

This means the HODL PR needs to add a test that performs a swap using the HODL invoices. As already said, I agree the method needs to be fixed, but I prefer first having a test that proves the bug. This approach helps avoid future regressions. I'll point out that a test doing a swap needs to be added to that PR.