Recurring x402 buyer guide omits the `assetTransferMethod: erc7710` seller requirement

I work on zFinia, an external x402 seller. I found this while checking whether a standard Base x402 v2 seller could be used with the recurring-payments buyer workflow; this is a docs/interoperability report, not a request for endorsement or a paid test.

The current recurring-payments workflow registers `x402Erc7710Client` for `eip155:*`, wraps `fetch`, and then says that when a server returns HTTP 402 the wrapped fetch creates a payment within the granted periodic budget and retries the request. The example call is an arbitrary `https://api.example.com/paid-endpoint`.

However, `packages/x402/src/x402Client.ts` currently does this before creating the delegation:

```ts
const assetTransferMethod = paymentRequirements.extra?.assetTransferMethod;

if (assetTransferMethod !== 'erc7710') {
if (this.#fallbackClient) {
return this.#fallbackClient.createPaymentPayload(...);
}
throw new Error(
`x402Erc7710Client can only process assetTransferMethod "erc7710"...`,
);
}
```

The recurring guide does not configure a `fallbackClient`, and I could not find `assetTransferMethod` mentioned in that buyer workflow. So a normal `exact` v2 seller that does not advertise `extra.assetTransferMethod: "erc7710"` appears to fail before a delegation payment is created, even though the guide currently reads as if an arbitrary x402 endpoint is sufficient.

Two small fixes seem possible:

1. If ERC-7710-aware sellers are intentionally required, state that explicitly before the `wrapFetchWithPayment` step and show the required payment-requirement extension.
2. If the buyer workflow is intended to work with ordinary `exact` sellers too, show a `fallbackClient` configuration and explain that only ERC-7710-capable challenges consume the delegated/session-key path.

A regression/docs test can stay fully mocked: one `PaymentRequirements` object with `extra.assetTransferMethod = "erc7710"` should use the delegation provider; one standard exact requirement without it should either fail with the documented limitation or use the configured fallback.

For disclosure, zFinia's current Base seller is the standard-exact case that exposed this distinction. I am not asking MetaMask to call it, pay it, or add it to examples.

Start with packages/x402/src/x402Client.ts and the recurring-payments buyer guide, then trace how wrapFetchWithPayment handles PaymentRequirements with and without extra.assetTransferMethod. Confirm the intended seller compatibility with maintainers, document either the ERC-7710 requirement or fallback behavior, and add the fully mocked regression/docs test described in the issue.

Written by the indexing model from the issue text.