[Feature/Roadmap] Implement MPP as a second payment rail (Machine Payment Protocol)

[SergeevDmitry]

Context & Rationale

x402 is currently the gateway's only implemented payment rail. Supporting
MPP gives merchants and buyer agents another interoperable
way to settle machine payments and tests the claim that payment providers are
pluggable independently of protocol adapters.

The first implementation should focus on MPP's one-time charge flow, which maps
cleanly to the gateway's existing request, settlement and receipt lifecycle.

Proposed Changes

• Add an MPP payment provider implementing the existing challenge, verification,
  settlement and health-check contracts.
• Support one-time charge payments for a documented network and asset profile,
  with deterministic amount conversion and replay protection.
• Allow merchants to select MPP in resource pricing configuration without
  changing MCP, HTTP or future protocol adapters.
• Map successful settlement and delivery into the existing commerce receipt,
  including a verifiable transaction reference.
• Replace the current planned placeholder with real configuration, capability
  and doctor reporting.
• Add end-to-end and negative tests using a real MPP client and a deterministic
  local settlement environment.

Non-goals / Invariants Preserved

• Subscriptions, sessions, streaming or usage-metered billing, cancellation and
  reconciliation are deferred.
• The gateway never holds buyer or merchant keys and never settles to a
  gateway-owned account.
• Payment verification does not move funds; settlement remains a separate step.
• Provider outages remain distinguishable from rejected payments, and adding
  MPP must not change the behavior of x402 or any protocol adapter.

Impact & Value

• Expands the set of buyer agents that can pay merchants through the gateway.
• Demonstrates that the payment-provider boundary works with more than one
  implementation.
• Keeps payment choice independent from resource discovery and invocation
  protocols.