feat: add p2pk_signing_keys to SendOptions

[vnprc]

Add p2pk_signing_keys: Vec<SecretKey> and allow_locked_proofs: bool to SendOptions so wallets holding P2PK-locked proofs can spend them through the standard prepare_send / confirm flow without a separate manual swap.

Behaviour

• When p2pk_signing_keys is non-empty and allow_locked_proofs is false (the default), all selected proofs are routed through a swap so the resulting token contains fresh, unconditioned proofs.
• Setting allow_locked_proofs: true opts in to the less-private passthrough path: proofs are signed and retain their spending conditions in the token. This is useful for multi-hop or offline flows where the next holder intentionally receives signed-but-still-locked proofs.

SIG_ALL incompatibility

SigFlag::SigAll is incompatible with passthrough signing: the signature would need to commit to swap outputs that do not exist at signing time. confirm() now calls enforce_sig_flag() on the proofs-to-send set and returns nut11::Error::SigAllNotSupportedHere early rather than silently producing an unspendable token.

Changes

• cdk-common: add p2pk_signing_keys and allow_locked_proofs to SendOptions, with doc comments explaining the SigAll incompatibility.
• cdk/wallet/util.rs: extract sign_proofs() with four unit tests covering correct key, wrong key, plain proof, and empty-keys cases.
• cdk/wallet/send/saga/mod.rs: shadow force_swap to true in internal_prepare when signing keys are provided and passthrough is not opted in; call sign_proofs() in confirm() for both proofs_to_swap (default path) and proofs_to_send (passthrough path); add SigAll check with an explanatory block comment before the passthrough signing block.
• cdk-ffi: add p2pk_signing_keys and allow_locked_proofs to FFI SendOptions and update both From conversions.
• Integration tests: add four pure tests covering the normal signing flow, the exact-denomination short-circuit regression, the passthrough opt-in, and the SigAll rejection.

Description

Add p2pk_signing_keys: Vec<SecretKey> and allow_locked_proofs: bool to SendOptions so wallets holding P2PK-locked proofs can spend them through the standard prepare_send / confirm flow without a separate manual swap.

Default behaviour (allow_locked_proofs: false): all selected proofs are routed through a swap, producing a clean token with no spending conditions. The caller provides signing keys only to authorize the swap inputs.

Passthrough (allow_locked_proofs: true): proofs are signed in-place and retain their spending conditions. Useful for multi-hop or offline flows where the next holder intentionally receives signed-but-still-locked proofs.

SigAll rejection: SigFlag::SigAll is incompatible with passthrough because the signature would need to commit to swap outputs that don't exist at signing time. confirm() detects this via enforce_sig_flag() and returns nut11::Error::SigAllNotSupportedHere early rather than silently producing an unspendable token.

Also fixes a force-swap short-circuit bug where proofs summing exactly to the send amount bypassed the swap entirely, causing locked proofs to escape into the token unsigned.

Test plan

• cargo test -p cdk wallet::util — 5 unit tests pass
• test_p2pk_send_options_signing_keys — normal signing flow
• test_p2pk_signing_keys_exact_denomination_short_circuit — force-swap regression
• test_p2pk_allow_locked_proofs_passthrough — passthrough opt-in
• test_p2pk_allow_locked_proofs_rejects_sig_all — SigAll rejection

---

Notes to the reviewers

---

Suggested CHANGELOG Updates

CHANGED

ADDED

REMOVED

FIXED

---

Checklist

• I followed the code style guidelines
• I ran just final-check before committing

[vnprc]

see #1750 for the first PR attempt

[lescuer97]

some comments around the code and proper flow

[vnprc]

thanks y'all. i rebased against main and all comments addressed. ready for another look

[vnprc]

@thesimplekid any ETA on this? should i rebase?

[thesimplekid]

This signability filter only checks the P2PK data key, but P2PK conditions can also require additional pubkeys via n_sigs. A proof where the wallet has the data key but not enough additional required keys will pass this filter, then fail later at swap/confirm with a mint rejection instead of being excluded as unsignable. Can this reuse the same requirements logic as verification, or sign and verify before treating the proof as selectable?

[thesimplekid]

In passthrough mode this signs only when a matching key is found, but it does not fail if no key is found or if the proof is only partially signed. That can create a token containing locked proofs that the recipient cannot redeem. Before creating the token, this should verify the passthrough proofs satisfy their spending conditions and return an error if they do not.

[thesimplekid]

This silently drops invalid FFI secret keys. ReceiveOptions uses a fallible conversion and returns an error for invalid p2pk_signing_keys; send should do the same so callers do not get a later InsufficientFunds or mint rejection caused by a key that was ignored during conversion.

[thesimplekid]

Noticed a few things and yes could you squash and rebase and we can get it merged thanks.

[vnprc]

ready for re-review. my agent also found an ffi bug that i will be opening a different pr to fix

[codecov]

Codecov Report

❌ Patch coverage is 89.44338% with 55 lines in your changes missing coverage. Please review.
✅ Project coverage is 66.23%. Comparing base (2018181) to head (25c274c).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/cdk/src/wallet/util.rs	84.67%	21 Missing ⚠️
crates/cdk/src/wallet/send/saga/mod.rs	94.27%	19 Missing ⚠️
crates/cdk-ffi/src/types/wallet.rs	36.36%	14 Missing ⚠️
crates/cdk-ffi/src/wallet.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1835      +/-   ##
==========================================
+ Coverage   65.91%   66.23%   +0.31%     
==========================================
  Files         330      330              
  Lines       58129    58641     +512     
==========================================
+ Hits        38317    38841     +524     
+ Misses      19812    19800      -12     

☔ 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.

[vnprc]

related bug fix: #1970

[vnprc]

oh shit my agent force pushed this branch. woops. i will try to reconcile the two force pushes.

[vnprc]

ah ok nm, it looks like codex did the right thing. please let me know if the force push was destructive. i tried to put guardrails in place but it seems like controlling agents is an impossible task. ¯\_(ツ)_/¯

[thesimplekid]

We can avoid needed the direct secp dep by just changing the error to not use transparent, I did this in this commit bf2757f. I also think it is more explixt and better if we use a enum vs the bool, I added that here c2d29dc. If you're happy with those changes I can merge and do any further rebasing once CI completes.

[vnprc]

LGTM

I have confirmed that hashpool mints ehash with this PR branch as it is. Sorry about the dependency churn, I need to work on my agent harness and put more human in the loop before pushing to a PR branch. Thanks for all the fee and enum improvements! Great stuff!