feat: log bazaar EXTENSION-RESPONSES header in resource servers

[ethanoroshiba]

Description

When the bazaar extension is configured on a resource server, the facilitator may return an EXTENSION-RESPONSES header on verify/settle responses containing the bazaar cataloging status (e.g. {"bazaar":{"status":"success"}}). This PR surfaces that data by reading the header in the HTTP facilitator clients (TypeScript, Go, Python) and logging an allowlisted subset of the extension fields.

Specifically:

1. After a successful verify or settle call, each HTTP facilitator client reads the EXTENSION-RESPONSES header, base64-decodes it, and logs the sanitized result as [x402] extension responses: ....
2. Only the fields status, rejectedReason, reason, and code are included in the log output — all other extension data is dropped before logging.
3. Malformed or absent headers are silently ignored.
4. Extension data is not merged into VerifyResponse or SettleResponse.

Tests

Unit tests passing. Formatting and linting verified per each language's CONTRIBUTING.md.

Checklist

• I have formatted and linted my code
• All new and existing tests pass
• My commits are signed (required for merge) -- you may need to rebase if you initially pushed unsigned commits
• I added a changelog fragment for user-facing changes (docs-only changes can skip)

[vercel]

@ethanoroshiba is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[up2itnow0822]

This EXTENSION-RESPONSES readback is exactly the piece paid MCP operators need once Bazaar search becomes part of discovery.

From the AgentPay MCP side, the production distinction we’re documenting is:

• Bazaar search/list tells an agent a paid MCP tool exists.
• EXTENSION-RESPONSES on verify/settle tells the operator whether extension processing actually succeeded, is pending, or was rejected.
• Payment approval still has to fail closed in the local policy layer; catalog success is not spend authority.

One interoperability note from implementing docs/tests against this: clients should treat four states differently in logs/UI — success, processing, rejected, and header absent/malformed. Missing readback should not be displayed as success.

We added the AgentPay MCP recipe and docs tests here for downstream consumers: up2itnow0822/agentpay-mcp#8

[phdargen]

Looks good @ethanoroshiba 👍 could you please add the EXTENSION-RESPONSES header to the facilitator examples, eg for TS https://github.com/x402-foundation/x402/blob/main/examples/typescript/facilitator/advanced/bazaar.ts, such that we have a valid reference implementation for this in the codebase?