UnifiedPayment::send applies the caller's amount inconsistently for fixed-amount instructions #1201

At main c32d3dd53638bce3d30522ffb9d52ad674f4578f, UnifiedPayment::send handles a caller-supplied amount inconsistently for PaymentInstructions::FixedAmount. The FixedAmount arm only rejects an amount below the instruction's amount. A larger amount then reaches the BOLT 12 branch, which calls send_using_amount whenever an amount is present and so pays the caller's larger value, whereas the BOLT 11 branch ignores the caller's amount and pays the invoice amount. The same URI therefore pays different amounts depending on which method succeeds, and an integration that always forwards a user-entered or default amount can overpay a fixed-amount offer without noticing.

Decide on one behavior for fixed-amount instructions and apply it across methods: either use send_using_amount only for ConfigurableAmount and call Bolt12Payment::send for fixed offers, or reject any caller amount that differs from the fixed amount up front with Error::InvalidAmount. Extend unified_send_receive_bip21_uri to send a fixed-amount URI with a larger amount and assert either an InvalidAmount error or that the receiver gets exactly the fixed amount, for both the BOLT 12 and the BOLT 11 fallback paths. The behavior was verified by reading; no PoC was run during triage.

This finding was discovered by Project Loupe.