fix(privateListings): reject mixed ERC20 payment tokens

[MrFaruk0]

Summary

Prevent private listing counter orders from aggregating payment items that use different ERC20 token contracts.

constructPrivateListingCounterOrder previously validated that all payment items were currency items and shared the same itemType, but did not verify that ERC20 items referenced the same token.

Problem

When multiple ERC20 consideration items use different token contracts, the helper currently aggregates their amounts into a single counter-order offer using the token from the first payment item.

For example:

• 100 TOKEN_A
• 20 TOKEN_B

would produce a single counter-order offer for:

• 120 TOKEN_A

The resulting fulfillment is later rejected by Seaport because offer and consideration components must match on token.

Solution

Extend the existing currency validation to also require payment items to reference the same token address before aggregation.

Token comparison is case-insensitive so differently-cased representations of the same Ethereum address remain valid.

This preserves the existing behavior for:

• multiple payment items using the same ERC20 token
• native currency payments
• zero-payment private listings
• existing mixed native/ERC20 rejection

Testing

Added regression coverage for:

• rejecting different ERC20 token contracts
• accepting differently-cased representations of the same ERC20 token

Validation performed:

• npx vitest run test/orders/privateListings.spec.ts
• npx vitest run
• npm run check-types
• npm run build
• git diff --check