Add Cashu charge method (draft-cashu-charge-01)

[orveth]

Adds specs/methods/cashu/draft-cashu-charge-01.md — the Cashu method binding for the MPP charge intent (HTTP 402 payment authentication settled with Cashu ecash).

Covers:

• Request shape { amount, currency, methodDetails: { request, mints } }
• JCS / RFC 8785 canonicalization of the request object
• Payment-Receipt response header on success
• Challenge expires enforcement
• RFC 9457 application/problem+json error responses

Internal review on the orveth fork before any upstream (tempoxyz) submission. Author / IANA Contact frontmatter still TODO.

[gudnuf]

take my questions and feedback and lets discuss what you think is the best approach by you replying to each comment where questions are asked or things are unclear. Also lets remove all the emdashes

[orveth]

Round 3 applied and pushed as e4819d0: every flat directive is in (abstract trim, intro paragraph, NUT-26 drop, step-3 fold + renumber to 9 steps, token-URL clause, spending-conditions section, client-split collapse, input-DLEQ paragraph, security-fees section, pubkey and P2PK material), every em-dash is gone (en-dashes too), and each of the 35 comments has an inline reply, including resolution pointers for the 6/08 batch.

Two design forks await your call before the conformance branch continues, recommendations inline on the respective threads: (1) payload.cashu_token casing (my pick: rename to payload.token), and (2) accept overpayment + drop both cashu-specific problem types (my pick: yes to both, with the 503 consumed-vs-unknown prose preserved verbatim). Both change the wire the code branch just built, so they settle first and apply to spec + code in one pass.

[gudnuf]

All right, here's some more review comments to discuss, and generally my thinking around this is based on first principles thinking where like I would rather delete as much as possible and not have stupid things in there that don't need to be in there and then only after we've kind of validated the idea do we start adding stuff based on review feedback and stuff? So based on the comments I left and everything else in the spec, let's think about What can be removed, potentially any ambiguities that need to be resolved or things that aren't clear And then also like things like nut ten and DLEQ, I feel like maybe we're adding too much complexity by saying that clients should validate the DLEQ and then also it would be much simpler if we just let any n spending condition through. So let's discuss this in discord before making any changes.

[orveth]

Round 5 applied in c938991 after the Discord walk-through: advertised nut10 spending conditions allowed (bearer-only check deleted, NUT-03 swap atomicity stated as the safety basis), all swap rejections unified under verification-failed with the cause in the problem detail, payment-expired single-cause, DLEQ down to one sentence, transport security to three, fees condensed, single_use pinned true, payment id pinned to the challenge id, userinfo and no-own-types lines deleted, digest+opaque and service-defined-unit examples cut (no sibling method carries either). Net: 1102 to 1011 lines, MUST count 61, verification steps renumbered 1-8, references and anchors rebalanced, zero em-dashes. Refund-path guidance intentionally omitted pending outside feedback.