Include Nonce in payer_metadata again

[jkczyz]

InvoiceRequest and Refund payer metadata originally contained a nonce used to derive the payer signing keys and authenticate any corresponding invoices. df5d7ea elided it once it was also included in the OffersContext of blinded reply paths, but that makes verifying a Bolt12Invoice depend on state outside the invoice itself. Upcoming payment proofs need the invoice signing keys derivable from the invoice request alone, so this includes the nonce in the payer metadata again and removes it from the outbound payment OffersContext variants.

The two commits:

• Include payer nonce in payer metadata again. Verify invoices via Bolt12Invoice::verify_using_metadata rather than the context's nonce, so Bolt12Invoice::verify_using_payer_data is removed.

• Remove nonce from outbound payment OffersContexts. Drop it from OffersContext::OutboundPaymentForOffer and OffersContext::OutboundPaymentForRefund, along with enqueue_invoice_request's nonce parameter. The payment_id is kept in both variants: it is no longer needed to verify the invoice, but is still used when handling a received Bolt12Invoice to confirm it arrived over the reply path created for that payment, preventing a payee from de-anonymizing us by minting invoices and delivering them to candidate nodes over other paths to observe which one we pay.

Compatibility

Invoices for invoice requests and refunds with blinded paths created by prior versions will no longer verify, since their payer metadata lacks the nonce; such outstanding payments will fail and must be retried with a new payment_id. Refunds without blinded paths are unaffected. Pending RetryableInvoiceRequests still persist the nonce, so payments retried after a downgrade continue to work.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

Consistent with my prior analysis. The slicing at line 326 is safe since it's only reached after verify_metadata confirms the length. The PR has not changed since my previous thorough review and no new concrete issues are present.

No issues found.

I re-verified the critical verification path (signer::verify_payer_metadata) and confirmed it remains internally consistent with the metadata format change (encrypted_payment_id || nonce). The IV-byte selection, derives_payer_keys() agreement between build and verify, the verify_using_metadata + extracted == payment_id substitution in flow.rs, the OffersContext/serialization cleanup, and RetryableInvoiceRequest.nonce: Option<Nonce> are all consistent with no dangling references or panics.

Cross-cutting note (non-blocking, for maintainer confirmation only): invoice requests created by the prior commit (df5d7ea7b) carry 32-byte payer metadata without the nonce. If such a request is still in flight across an upgrade, the new verify_using_metadata path would reject the returning invoice. The downgrade direction is handled via the retained nonce field, and this format appears to have been unreleased, so this is likely acceptable.