feat: add preferred_mints to payment requests

[a1denvalu3]

Summary

• Add support for preferred_mints to Cashu Payment Requests (NUT-18 and NUT-26)
• Update PaymentRequest and CreateRequestParams structs with preferred_mints across core, wallet, CLI, and FFI
• Ensure mints and preferred_mints are mutually exclusive during creation and decoding
• Update wallet pay_request selection logic to prioritize preferred_mints over fallback mints if they have sufficient balance

[codecov]

Codecov Report

❌ Patch coverage is 81.40351% with 53 lines in your changes missing coverage. Please review.
✅ Project coverage is 66.37%. Comparing base (edafe26) to head (0250e4e).

Files with missing lines	Patch %	Lines
crates/cdk/src/wallet/payment_request.rs	52.54%	28 Missing ⚠️
crates/cashu/src/nuts/nut18/payment_request.rs	82.65%	17 Missing ⚠️
crates/cdk-ffi/src/types/payment_request.rs	78.12%	7 Missing ⚠️
crates/cashu/src/nuts/nut26/error.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1925      +/-   ##
==========================================
+ Coverage   66.24%   66.37%   +0.12%     
==========================================
  Files         330      330              
  Lines       58633    58900     +267     
==========================================
+ Hits        38841    39092     +251     
- Misses      19792    19808      +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lescuer97]

LGTM. The errors in the CLI seem to be clippy and other errors not related to the code

[thesimplekid]

Can you rebase instead of merge https://github.com/cashubtc/cdk/blob/main/DEVELOPMENT.md#keeping-your-branch-up-to-date please

[a1denvalu3]

Can you rebase instead of merge https://github.com/cashubtc/cdk/blob/main/DEVELOPMENT.md#keeping-your-branch-up-to-date please

I usually rebase, but the update button under the PR was too tempting this time.

[cdk-bot]

Verified findings approved for disclosure:

• Duplicate supported_methods fields make the benchmark example fail to compile (high) - The cashu example/test target fails to compile because duplicate fields in a Rust struct literal are a hard error, blocking workspace all-target builds/tests/clippy.
• NUT-26 encode path can emit requests that decode rejects (low) - The public NUT-26 encoder can successfully emit payment requests that the PR's own decoder rejects as invalid, breaking encode/decode round trips for directly constructed PaymentRequest values with both mint lists populated.
  Unanchored locations included in summary:
  • crates/cashu/src/nuts/nut18/payment_request.rs:72

[cdk-bot]

This struct literal now specifies supported_methods three times. Rust treats duplicate fields in a struct initializer as a hard compile error (E0062), so the cashu example/test target will not build. Could you remove the two extra supported_methods: vec![], entries and leave just one?

[cdk-bot]

Should encode_tlv reject the same mints + preferred_mints combination that from_bech32_bytes rejects? Right now a caller can construct a public PaymentRequest with both vectors populated, to_bech32_string() succeeds and writes both tag 0x05 and 0x09, but the resulting request fails to decode with MutuallyExclusiveMints (the new test at the bottom demonstrates this by unwrapping the encode and then asserting decode fails). Since to_bech32_string() already returns Result, adding the same check before writing either mint list would prevent emitting an invalid CREQ-B request.