feat: LNURL-pay server for self-hosted Lightning Addresses

[DoktorShift]

Goal

NUTbits can optionally serve as an LNURL-pay provider so users can create Lightning Addresses backed by their ecash mint. Paying the address triggers the existing make_invoice flow — ecash lands in NUTbits.

payer → Lightning Address → NUTbits LNURL server → make_invoice → Cashu mint → ecash in wallet

The created address can be attached to NWC connections via &lud16= (#2).

Scope

• GET /.well-known/lnurlp/<username> — LUD-06 metadata response
• Callback endpoint — receives amount, calls make_invoice, returns Lightning invoice
• Address management: create, list, delete (CLI + API)
• Config: NUTBITS_LNURL_DOMAIN, min/max amounts, enable/disable
• Off by default — must be explicitly enabled. NUTbits runs fine without it.

Hints

• Read LUD-06 and LUD-16 specs — they're short
• make_invoice already exists — the LNURL callback just triggers it via HTTP
• The existing HTTP server in api/server.js can host these routes
• Consider: open amounts (payer chooses), what happens when username doesn't exist
• References for context: npubcash-server, @candypoets/lnuts — similar Cashu+LNURL approaches, but they deliver tokens via Nostr DMs. NUTbits doesn't need that — the ecash stays in the wallet.

Acceptance

• nutbits address create <username> creates a Lightning Address
• .well-known/lnurlp/<username> serves valid LNURL-pay responses
• Paying the address results in ecash arriving in the wallet
• nutbits address list / nutbits address delete
• Address can be attached to NWC connection via &lud16= (feat: support lud16 parameter on NWC connection strings #2)

Depends on

#2 — for attaching the created address to NWC strings