feat(api): add /payinvoice endpoint for outbound BOLT11 payments

[martinsaposnic]

Summary

Adds POST /payinvoice so mdkd can send Lightning payments, not just receive
them. Calls node.bolt11_payment().send() for amount-bearing invoices and
send_using_amount() for zero-amount invoices. Returns {paymentId, paymentHash}
so callers can poll the existing GET /payments/outgoing/{paymentId} for status.

This is required for using mdkd as the agent-wallet engine on Cloudflare
Containers (single shared wallet across a worker deployment, with both
receive and send needed for autopayouts and tipping).

Endpoint

• POST /payinvoice (tag: send, full-access auth)
  • Form-encoded body:
    • invoice (required): bolt11 string
    • amountSat (optional): only for zero-amount invoices
  • Response: {paymentId, paymentHash} (camelCase)
  • 400 if the invoice carries an amount AND amountSat is set, or if the
    invoice is zero-amount AND amountSat is missing

Files

• src/daemon/api/pay.rs (new) - handler
• src/daemon/api/mod.rs - route registration in full_routes, OpenAPI schema
• src/daemon/types.rs - PayInvoiceRequest / PayInvoiceResponse
• tests/integration.rs - new tests (see below)
• tests/common/mod.rs - PayerNode::create_invoice and outbound_capacity_msat helpers

Naming convention note

amountSat (sat units) intentionally diverges from eclair's amountMsat
(msat) to stay consistent with the rest of mdkd's existing surface
(/createinvoice, /getbalance, all incoming-payment fields use sat).
The endpoint name and invoice parameter follow eclair. Optional eclair
params (maxAttempts, maxFeeFlatSat, maxFeePct, externalId,
blocking) are deferred until there's a concrete caller use case.

Tests added

• test_payinvoice_outbound_payment - end-to-end pay flow. mdkd is
  funded via an inbound JIT-channel payment from the LSP-connected
  PayerNode, then issues /payinvoice for a fresh invoice that same
  payer node generated. Asserts paymentId/paymentHash shape, polls
  /payments/outgoing/{paymentId} until isPaid=true, asserts sent +
  fees + preimage, and waits until the payer node observes the
  inbound 50k sat in its lightning balance to defend against silent
  routing failures.
• test_payinvoice_invalid_bolt11 - 400 + bad_request when the
  invoice string fails to parse.
• test_payinvoice_amount_conflict_400 - 400 + bad_request when
  an amount-bearing invoice is paired with an amountSat override.

Test plan

• cargo fmt --check
• cargo clippy --all-targets -- -D warnings
• cargo nextest run integration coverage for the happy path and
  both validation-error paths (will run in CI; local nix sandbox
  hits a pre-existing daemon::secret::tests FD-3 failure that
  also fails on origin/master, unrelated to this branch).
• Manual: paid a 1500 sat mutinynet faucet invoice from a signet
  mdkd built off this branch. fee 1 sat, isPaid: true, balance
  went 3430 -> 1929.
• Manual: deployed mdkd to a Cloudflare Container (built from this
  branch), called POST /payinvoice from a Worker, paid a 1000 sat
  faucet invoice, polled GET /payments/outgoing/{paymentId} until
  isPaid=true. fee 1 sat.

[amackillop]

Should throw a bad request error if the request amount does not match the invoice amount

[amackillop]

Left this on the wrong line. I think it is fine if both are set as long as they match. Curious what phoenixd does here

[martinsaposnic]

1152a95

[amackillop]

Looks good. One minor comment