feat(x402): attach BlockRun builder-code service code to payments

[KillerQueen-Z]

What

Tags every x402 payment this SDK signs with the ERC-8021 Schema 2 service code s: ["blockrun"], so payments originated through BlockRun's client SDK are attributed to BlockRun on-chain.

Reference: CDP Builder Codes

How

• New helper withBuilderCodeServiceCode() merges s: ["blockrun"] into the payload's builder-code.info, preserving any app code (a) the server echoes back in its 402 response (so we never clobber seller attribution).
• Wired into both payload builders — EVM (createPaymentPayload) and Solana (createSolanaPaymentPayload).
• The service code is exported as BLOCKRUN_SERVICE_CODE for reuse.

Why this is all the client needs

The CBOR / ERC-8021 calldata encoding is done by the CDP facilitator at settlement time (it reads builder-code.info.s from the payment payload). The client only sets a JSON field — so this needs no new dependency, no @x402/extensions, no CBOR and works unconditionally on every payment.

Scope / inheritance

This SDK (@blockrun/llm) is the payment layer for @blockrun/mcp, @blockrun/clawrouter-codex, and other TS consumers — they inherit this attribution automatically once they bump to the released version.

Buyer-side only. Seller-side app code (a) on the gateway is tracked separately (needs a registered code from dashboard.base.org).

Test

• Added 2 cases to test/unit/x402.test.ts: service code is always attached; server-echoed a is preserved when s is added.
• Full suite green: 197 passed, typecheck clean.

[VickyXAI]

Reviewed and verified with a live settle — merging.

The signature is provably untouched. signTypedData covers only {from, to, value, validAfter, validBefore, nonce} under TRANSFER_TYPES/TransferWithAuthorization. extensions is not in message, not in the types, not in domain — this diff touches exactly one key of the outer envelope. amount, payTo, validity window and nonce are byte-identical before and after. Same holds on the Solana path.

The one thing tests couldn't prove was CDP's acceptance of an unregistered s code — and the blast radius there is total, since this SDK is the payment layer for both @blockrun/mcp and ClawRouter. If the facilitator errored on an unrecognized service code, every payment on every chain breaks. So I tested it rather than assume:

built this branch → installed into blockrun-mcp → one real x402 call on Base
  blockrun_markets polymarket/markets  → real market data, isError: false
  wallet 64.902027 → 64.899027         → settled, CDP accepted s:["blockrun"] ✓

The a-preservation is correct too — { ...(existing.info || {}), s: [...] } merges rather than replaces, so a server-echoed app code survives.

Two non-blocking notes for later:

1. s is unconditionally overwritten, so a caller passing their own extensions["builder-code"].info.s gets silently clobbered. Fine while we're the only consumer; a footgun if the SDK gains external ones.
2. This branch is based on 3.5.1 — main is 3.6.1 now. The patch sites are unchanged so it applies cleanly, but the version bump for release should come off current main.

Thanks — and same as #47, the diff was tight and easy to reason about.