docs: clarify EVM channel and transfer method semantics

[EfeDurmaz16]

Summary

• Correct the batch-settlement voucher docstring for channelId so it points to the EIP-712 ChannelConfig hash used by computeChannelId
• Clarify that omitted extra.assetTransferMethod in EVM exact PaymentRequired means the default eip3009 method
• Add the same defaulting note to the HTTP transport example, where extra.assetTransferMethod is intentionally omitted

Fixes #2323

Verification

• pnpm --dir typescript/packages/mechanisms/evm exec prettier -c .prettierrc --check src/batch-settlement/client/voucher.ts ../../../../specs/schemes/exact/scheme_exact_evm.md ../../../../specs/transports-v2/http.md
• pnpm --dir typescript/packages/mechanisms/evm exec vitest run test/unit/batch-settlement/utils.test.ts
• pnpm --dir typescript/packages/mechanisms/evm lint:check
• git diff --check

[vercel]

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

A member of the Team first needs to authorize it.

[Adelagric]

Thanks for picking this up quickly. The fix matches both points from #2323.

For independent confirmation on the channelId one: I implemented batch-settlement in Rust and compute channelId as the EIP-712 typed-data hash of ChannelConfig (keccak256(0x1901 ‖ domainSeparator ‖ hashStruct)), the way computeChannelId does — not keccak256(abi.encode(...)) as the old docstring read. Golden tests decode the verbatim Base64 vectors from specs/transports-v2/http.md and reproduce channelId, the Voucher digest and signer recovery byte-for-byte against viem. So the corrected docstring reflects the actual on-the-wire semantics; the previous wording would have sent an implementer to a wrong preimage.

Same holds for the assetTransferMethod default — modelling it as required fails to parse the canonical PaymentRequired; optional with an eip3009 default is correct.

Happy to share the EIP-712 vectors as conformance fixtures if that's useful for the EVM tests.