Expose original BOLT11 invoice for manually claimable payments #284

Motivation

Bolt11ReceiveForHash returns the created BOLT 11 invoice, but that invoice cannot be recovered later through the gRPC API.

This becomes a problem for durable clients handling manually claimable payments. A client may create a hold invoice, restart, and later receive PaymentClaimable. That event contains the payment ID, types.Payment, custom records, claim deadline, and claimable amount, but not the original invoice. GetPaymentDetails and ListPayments also return types.Payment, whose BOLT 11 variant contains the hash, preimage, secret, and skimmed fee, but no invoice.

Without the original invoice, a client first observing or reconciling the payment cannot recover invoice fields such as:

• description or description hash
• expiry
• requested amount for fixed-amount invoices
• payment metadata
• route hints

This prevents clients from building a complete durable transaction record for a held payment. It also means DecodeInvoice cannot help, because that RPC requires the invoice string as input.

Requested behavior

Provide a way to recover the original BOLT 11 invoice for payments created through Bolt11ReceiveForHash, including after ldk-server restarts.

Possible API shapes include:

1. Add an optional bolt11_invoice field to PaymentClaimable.
2. Persist the invoice with payment state and expose it through types.Bolt11, making it available from PaymentClaimable, GetPaymentDetails, and ListPayments.
3. Add a dedicated invoice lookup RPC keyed by payment ID or payment hash.

Exact shape is open for discussion. Required property is durable retrieval after the original Bolt11ReceiveForHash response is gone. An event-only field without persistence would not support restart reconciliation.

Compatibility

This can be additive at the protobuf level using a new optional field or RPC. Existing clients would remain compatible. Payments created before invoice persistence was introduced could return the field unset or NotFound.

Related issues

• SubscribeEvents: support resuming from an event index for reliable at-least-once delivery #245 tracks resumable event delivery. This issue is separate: even a successfully delivered PaymentClaimable currently lacks the original invoice, and listing/detail APIs cannot recover it.
• Expose LDK Node data currently dropped at the gRPC boundary #251 tracked other LDK Node fields dropped at the gRPC boundary, but did not cover BOLT 11 invoice persistence or retrieval.