Expose InputPair outpoint over FFI

[chavic]

This exposes the outpoint carried by a receiver InputPair through a small outpoint() accessor and regenerates the C# binding surface.

BTCPay uses WantsInputs::try_preserving_privacy through UniFFI in ValeraFinebits/btcpayserver-payjoin-plugin#59. The selected InputPair crosses the FFI boundary as an opaque object, while BTCPay keeps spendable wallet metadata in its own ReceivedCoin model. BTCPay needs the selected input OutPoint to map that choice back to the coin it can reserve across sessions and later sign.

Disclosure: co-authored by GPT-5 Codex

[coveralls]

Coverage Report for CI Build 28107957766

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage decreased (-0.006%) to 85.218%

Details

• Coverage decreased (-0.006%) from the base build.
• Patch coverage: 10 of 10 lines across 1 file are fully covered (100%).
• 64 coverage regressions across 3 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

64 previously-covered lines in 3 files lost coverage.

File	Lines Losing Coverage	Coverage
payjoin-mailroom/src/lib.rs	42	67.67%
payjoin-mailroom/src/ohttp_relay/mod.rs	11	82.61%
payjoin/src/core/receive/v2/mod.rs	11	91.28%

---

Coverage Stats

Relevant Lines:	14761
Covered Lines:	12579
Line Coverage:	85.22%
Coverage Strength:	369.92 hits per line

---

💛 - Coveralls

[DanGould]

Based on our conversation this seems like the right approach but I want to validate that before this gets merged.

PR draft in the BTCPayServer plugin implementation pointing to this PR's commit hash (or even branch name, since it's just a draft) would proving this is the right shape to solve the problem. That'll serve as draft to merge there as soon as this pr is merged/released anyhow so it's nothing extra than needs to be done no matter what.

Showing where this is needed in the BTCPayServer plugin will also reveal the counterpart (or lack thereof) in the payjoin-cli reference and make sure that the reference covers this usecase. I'd like to see some sort of link to where the similar behavior exists in payjoin-cli in the PR body and in the BTCPayServer PR.

I think outpoint makes a lot more sense since that refers to the specific txid+index that's needed and is a distinct thing from "Previous output" which ime refers to the complete information of the transaction output, not just the reference that the outpoint serves as. The in-flight terminology BIP is a great resource for customary naming of transaction parts like this.

Finally, I want to make sure it makes sense to expose this exact data as an accessor rather than any subfield of the InputPair itself, which a reference to payjoin-cli should bring to light. I know UniFFI gives us options in terms of Record field/Record method/Object method to return an outpoint and would like to see rationale of why the chosen approach is the right one among the available options.

[DanGould]

Oh, and if this were my PR and I couldn't find a reference to this behavior in payjoin-cli, I'd go and find out why the other implementaitons didn't need this accessor, and then write up either why BTCPayServer is a unique case that requires this or update the BTCPayServer Plugin to use the same pattern as the others.

[chavic]

Seems BTCPay cannot exactly match payjoin-cli because BTCPay’s wallet model keeps UTXO metadata in a type called ReceivedCoin. The payjoin library selects an opaque FFI InputPair, but BTCPay must map that selection back to the ReceivedCoin type so it can reserve the coin across sessions and sign it later. The CLI avoids this because its wallet boundary already returns InputPairs and contributes the selected one directly.