[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 existing request, settlement and receipt lifecycle.

How a buyer chooses between x402 and MPP on the same resource is handled by the payment-rail selection issue; this issue adds the provider that plugs into it rather than a per-resource switch.

Proposed Changes

• Pin one MPP profile before implementation: spec revision, client, charge method, network, asset and settlement destination, each linked to the corresponding page on mpp.dev. Support is claimed for that profile only.
• Confirm that the profile allows verification without moving funds. If MPP's one-time charge flow combines verification and settlement, resolve that at the payment-provider contract level first; do not hide it inside the provider.
• Add an MPP payment provider implementing the existing challenge, verification, settlement and health-check contracts, with deterministic amount conversion.
• Derive the replay key from the underlying authorization, provider, network and asset. Request IDs alone are not replay protection.
• Treat a settlement whose result is never received as unresolved, with or without an external reference. An unresolved attempt is not marked failed and is never retried on another rail.
• 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, including one resource that advertises both x402 and MPP, with the headers or fields each rail uses on HTTP, MCP and A2A documented. If the upstream environment cannot provide deterministic settlement, state that in the PR instead of mocking around it.

Non-goals / Invariants Preserved

• Subscriptions, sessions, streaming, usage-metered billing, cancellation and reconciliation are deferred.
• Offer advertisement and buyer-side rail selection are out of scope here.
• 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, rejected payments and unknown outcomes remain distinguishable. Adding MPP must not change the behaviour of x402 or any protocol adapter.
• MPP dependencies are optional and loaded only when the provider is enabled.

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: the same resource carries both rails, a merchant accepts MPP without touching the backend integration, and receipts, errors and recovery describe a purchase the same way whichever rail was used.
• Keeps payment choice independent from resource discovery and invocation protocols.
• If MPP turns out to need a change to core business semantics, the provider boundary is wrong - and that is a finding worth this issue on its own.