feat: add native wsteth support

[tx-nikola]

• Tested withdraw, deposit, and transfer for the native wstETH token, as well as the bridged (erc20) one, also tested ETH token and others to not mess up the previous flow.

• The custom gas price fetching and custom withdraw tx creation had to be added since newer version of the SDK works in a different way for bridge addresses and it didn't work with native wstETH address

• The balances/tokens map had to be updated - previously it used L1 address as the key, but I had to change it so that it uses the L2 address as the key - since we want to keep backward compatibility with the previous bridged (non-native non-Lido) wstETH token, so we want to support both, but they have the same L1 address, so we couldn't use the L1 address as the key

This PR fixes https://github.com/matter-labs/dapp-portal/issues/238

[github-actions[bot]]

Visit the preview URL for this PR (updated for commit 7ec2240):

https://staging-zksync-dapp-wallet-v2--pr246-tx-nikola-txfusio-3ifj5qui.web.app

_{(expires Tue, 15 Jul 2025 18:26:59 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: a25831e6058958ccabf0f806505b5b8e7241b178}

[tx-nikola]

I didn't use AI for any of the mentioned parts - those were basically examples for how we did it previously, but I agree with the comments and I agree that it could be polished!

Updated based on the comments:

• Now we use the getL1VoidSigner for the signer (which under the hood uses onboardStore.getPublicClient())

• Removed the networkType part as it's not needed, because the l1 signer handles that part now

• I left the allowance part - the reason I added it for the handleCustomBridgeDeposit function is because before, when calling wallet.deposit, we pass the approveBaseERC20 as true

• Tested wstETH for both withdraw and deposit

[tx-nikola]

@JackHamer09

• Removed all occurencies of this pattern:

{
<object properties>,
...(transaction.value.token.l2BridgeAddress ? { bridgeAddress: transaction.value.token.l2BridgeAddress } : {}),
}

I used it because in some cases in other projects, I found it that some functions that expect object params, expect either an object with a parameter or with no parameter, and even if we pass "undefined" as a param, the function will take it as a param that exists, and potentially throw an error - so I just adopted the style that if I pass the object with potentially undefined params, I don't pass the params that would be undefined. In these cases it doesn't make a difference, so I agree with you to keep it simplified.

• I updated changes for tokens.ts to not be hacky
  • Instead of mapping L1 and L2 token objects in a complicated way, I created new mapper functions in helpers.ts and use them wherever we need balances/tokens arrays. Before, it was hacky because I was trying to change the object mapping - it was {[l1Address]: Token} because the object keys must be unique and there can't be 2 same L1 addresses (as we have in the case of wstETH) but now I left it as it is and just map it whenever we use the array.

[github-actions[bot]]

:tada: This PR is included in version 1.44.0 :tada:

The release is available on:

• v1.44.0
• GitHub release

Your semantic-release bot :package::rocket: