Fix shouldRetry not retrying QuickNode's -32007 rate-limit code

[Eras256]

Fixes #5082

Summary

shouldRetry handles the JSON-RPC-level 429 code (Alchemy's rate-limit
signal, added in #4424) but doesn't handle QuickNode's own non-standard
rate-limit code, -32007 ("N/second request limit reached..."). This
means retryCount on the http() transport is silently ignored for
QuickNode rate limits specifically — the request fails on the very first
attempt regardless of how high retryCount is set.

This isn't hypothetical: it's the exact failure mode that caused a real
production incident for us against a QuickNode Base endpoint.

• Added error.code === -32007 to the retryable codes in shouldRetry,
  mirroring the existing 429 special-case.
• Added a unit test for shouldRetry with a -32007 error code,
  matching the style of the existing 429 test.
• Added a changeset.

Test plan

• src/utils/buildRequest.test.ts — new shouldRetry > RPC code -32007 (QuickNode rate limit) test.
• Could not run the full local suite in this environment (needs a
  Foundry/Anvil toolchain this sandbox doesn't have), so I also verified
  the exact patched branching logic in isolation against six cases
  (the new -32007 case, the three already-passing retryable codes,
  and two non-retryable codes) before opening this PR.

[vercel]

@Eras256 is attempting to deploy a commit to the Wevm Team on Vercel.

A member of the Team first needs to authorize it.

[changeset-bot]

🦋 Changeset detected

Latest commit: 36cbc4b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
viem	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR