test: demonstrate callstack in extended client action

[holic]

Continued from #2675

• replaces base actions to avoid RPC calls
• demonstrates callstack of inner action calls

---

PR-Codex overview

The focus of this PR is to refactor and extend action composition in the createClient module.

Detailed summary

• Added type definition for Client
• Refactored action composition logic in createClient
• Added new actions getChainId and estimateGas
• Updated tests to reflect changes in action composition logic

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[changeset-bot]

⚠️ No Changeset found

Latest commit: a701aa8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[vercel]

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

A member of the Team first needs to authorize it.

[holic]

This is the functionality I was trying to understand, where I hoped that this would look more like

[
  'estimateGas:second',
  'estimateGas:first',
  'estimateGas:base',
  'getChainId:second',
  'getChainId:first',
  'getChainId:base',
]

[jxom]

Could consider binding them (in Viem) to behave like this.

[holic]

I'm not sure of the consequences of that. Would that be a breaking change because it would change the behavior of the entire callstack of extended clients?

I was thinking of writing a separate "compose" decorator wrapper that could handle this.