fix(x402): authenticate explicit payment requests

[AkshatGada]

Calling client.x402.withPayment() immediately after createClient({ apiKey }) can send the protected secret GET before user-key authentication finishes or without exchanging an agent key. Its direct fetches also omit configured DPoP/runtime headers and reuse the original Bearer token after payment signing.

Route both requests through the existing authenticated rawRequest() transport. Each attempt now waits for authentication, refreshes eligible agent tokens, and builds current headers. Explicit signer selection, payment amount/payload semantics, one paid retry, and resource response envelopes are preserved without activating automatic payment.

Failed agent-token exchanges now reject through the shared transport before dispatch, matching other authenticated resources. The existing user-key exchange failure handling is unchanged.

Testing

On Node 22.23.3:

npm run build
node node_modules/vitest/vitest.mjs run src/__tests__/x402.test.ts src/__tests__/http.test.ts src/__tests__/client.test.ts --reporter=verbose
node node_modules/vitest/vitest.mjs run
git diff --check

• Focused checks: 40 passed, including 20 new payment-helper cases.
• Full suite: 198 passed across 9 files, with the public 1claw-openapi-spec checked out alongside the SDK as current CI requires.
• Separate TypeScript check of the new test and its production imports passed.

HTTP, payment signatures, and DPoP generation are mocked in the regression tests. These checks cover request construction and control flow; no live authentication, payment settlement, or server-side DPoP acceptance was tested.

[AkshatGada]

@kmjones1979, with withPayment() now using rawRequest(), should getPaymentRequirement() also await authentication, or is anonymous probing intentional? On a fresh API-key client, it can currently turn a 401 into null, which its docs describe as no payment required.