feat(cli): support x402 payment challenges

[brendanjryan]

Motivation

Supersedes #812 by allowing the CLI to pay x402-only endpoints directly.

Summary

• Added --protocol auto|mpp|x402 challenge selection.
• Added x402 EVM signing and PAYMENT-SIGNATURE request handling.
• Documented the option and covered protocol selection, asset filtering, and failure paths.

Key design considerations

• Automatic mode retains MPP-first selection while degrading safely around malformed x402 co-offers.
• The selected challenge retains protocol provenance through credential creation.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/mppx@850

commit: efccf3c

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 68bb4ccaad

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[safal207]

The redirect hardening here exposed a useful protocol-level invariant, so I turned it into a small protocol-neutral red/green conformance fixture in AgentProof/Astra:

• red: origin A redirects to B, B issues the accepted x402 challenge, and the same typed payment authorization is observed at both A and B → PAYMENT_CREDENTIAL_ORIGIN_DIVERGENCE + CROSS_ORIGIN_CREDENTIAL_REUSE;
• green: the credential-bearing retry goes directly to B, dispatch and consumer evidence carry the same typed authorization identity, and one settlement, receipt, delivery, and reconciliation agree.

Merged implementation and claim boundary: safal207/safal207-AgentProof-AI#19

The red fixture deliberately contains no settlement event: it proves credential exposure, not historical theft, consumption, or duplicate payment.

One contract question: should the challenge origin be the normative credential recipient for every reusable x402 credential, or do you expect authenticated intermediary/delegate origins? If delegates are intended, what exact artifact should establish that authorization so a client or independent verifier does not infer it from redirects or proxy topology?