LUD-XX: verifyBatch — batched and streamed settlement checking for LNURL-verify

[Kukks]

LUD-21 gives one verify URL per invoice, checked with one GET. A merchant backend tracking N pending invoices against a single LNURL-pay endpoint (say a BTCPay Server instance behind a Lightning address) ends up making N requests per poll cycle, and settlement latency is stuck at the poll interval — awkward when checkout wants sub-second confirmation.

This proposes an optional verifyBatch endpoint, advertised alongside verify in the LUD-06 callback (and optionally in LUD-21 verify responses, so already-deployed clients can pick it up mid-flight). One GET checks a whole set of pending invoices at once. The same endpoint answers in two ways depending on the Accept header: a one-shot JSON snapshot by default, or an SSE stream (Accept: text/event-stream) that sends the snapshot first and then pushes settlements as they happen — openable directly with a browser EventSource. There is no capability flag: a service that does not stream just ignores the header and returns the snapshot, so a client that hoped for a stream still gets a usable answer and falls back to polling.

It stays inside LUD-21's trust model exactly. A caller only ever learns about verify URLs it already holds; each supplied URL is looked up against what the service issued and is never fetched (so no request-forgery surface); and every returned key is echoed byte-for-byte so the client's opaque-URL lookup still matches. It is optional and additive — a LUD-21-only service or client is unaffected, and a single invoice still just uses the plain verify GET.

Worth flagging for discussion: this overlaps with #281 (long-held request for LUD-21 verify). They come at overlapping problems from different angles — #281 removes the latency floor for a single invoice by holding one request open per URL, while verifyBatch covers a whole pending set on one connection and also removes the N-requests-per-poll cost. They are compatible, and a service can implement either or both. If the group would rather fold the streaming idea into #281's single-endpoint approach, or name the field differently, I am happy to adjust.

Filed as XX.md per CONTRIBUTING (no self-assigned number); happy to renumber at merge. This is a draft for feedback, and I have not touched the README index or the dependency graph — glad to add those once a number is assigned.