Make an LNURL-pay extension to handle intra-ASP payments (`client=ark`)

[niteshbalusu11]

Description

Recent discussion highlighted ambiguity around using client=ark versus wallet=<walletname> in payment requests/metadata, and what guarantees each implies.

Key points:

• wallet=<walletname> (e.g., wallet=noahwallet) is effectively proprietary and can assume Ark-only handling (i.e., can guarantee no Lightning invoice is needed).
• client=ark is intended to be more interoperable, enabling wallets to detect whether a destination ASP is supported.
• If client=ark is used and the destination ASP is not supported, the sender may need to fall back to providing/using a Lightning invoice.
• This could be important for scenarios like offline payments and cross-wallet payments, but it requires a clear spec.

Context

• There was a request to consider making breaking changes early if moving from wallet=noahwallet to client=ark is desired, to avoid doing it later.
• It was clarified that wallet=noahwallet cannot be replaced outright with client=ark because client=ark cannot guarantee Ark-only settlement and may require LN fallback.
• Agreement that a specification is needed before implementing or relying on this behavior.

Expected Behavior

• Define a spec that clearly states:
  • The intended semantics of client=ark vs wallet=<name>.
  • What a sender must include when using client=ark (e.g., ability to provide LN invoice / LN fallback path).
  • How wallets should determine “supported ASP” and how that is represented/verified.
  • Whether and how this enables offline payment flows.
  • Backward compatibility expectations and whether any breaking changes are planned.