[Feature/Roadmap] Implement A2A (Agent2Agent) protocol support

[SergeevDmitry]

Context & Rationale

The gateway currently exposes merchant resources to agents through MCP. Agents
that use A2A cannot discover
or invoke those resources without a separate integration.

Adding A2A also validates an important architectural goal: new agent protocols
should map into the existing execution pipeline without changing the commerce
core or implementing payment logic a second time.

Proposed Changes

• Add an A2A adapter that publishes an Agent Card and exposes configured
  merchant resources as discoverable skills.
• Support synchronous resource invocation and map requests and results at the
  adapter boundary.
• Route every invocation through the existing execution pipeline, including
  pricing, payment enforcement, backend execution and receipts.
• Surface the existing payment-required response for paid resources so A2A
  does not introduce a separate payment model.
• Add configuration, capability reporting, doctor diagnostics and protocol
  documentation for the adapter.
• Add interoperability tests using a real A2A client for free, paid and invalid
  requests.

Non-goals / Invariants Preserved

• Streaming, push notifications and long-running task management are deferred;
  the current gateway execution model is synchronous.
• A2A-specific types stay outside the core domain.
• Adapter failures must remain isolated and must not affect MCP or gateway
  availability.
• No request may reach a merchant backend without passing through the shared
  execution and payment checks.

Impact & Value

• Makes configured merchant capabilities available to the growing A2A agent
  ecosystem.
• Proves that the protocol-adapter architecture extends beyond MCP.
• Preserves one payment and receipt model across agent protocols.