Modals Fetch Listings Using Wrong Account Address

[Yashiru]

Issue description

The CancelListingModal and EditListingModal components seem to have a limitation when using a custom walletClient that supports multiple accounts, such as an abstract global wallet in my case.

Note

I have tested this issue with the CancelListingModal and EditListingModal components, but it is possible that other components might be affected as well.

In my specific use case, my custom walletClient contains two accounts as described in the AGW doc:

• An EOA account
• A smart contract wallet account that holds the NFTs I want to manage using ReservoirKit.

The issue arises because these modals rely on the useAccount hook from Wagmi to fetch the account address. This address corresponds to my EOA, not the smart contract wallet.
As a result, the modals fail to detect my listings because they make requests using the wagmi account like:

https://api-abstract-testnet.reservoir.tools/users/{MY_EOA_ADDRESS}/asks/v1?ids={LISTING_ID}

Instead of using the smart contract wallet address available in the custom walletClient provided upper.

Expected Behavior

The modals should detect and use the account address from the provided walletClient when it's available, rather than always defaulting to the address from useAccount.

Steps to Reproduce

Use a custom walletClient from Abstract Global Wallet
Provide the walletClient to the ReservoirKit modal CancelListingModal or CancelListingModal components like:

const { data: client } = useGlobalWalletSignerClient();
...
<EditListingModal
    trigger="manual"
    walletClient={client}
    listingId={LISTING_ID}
    openState={editListingModalOpen}
    collectionId={YOUR_COLLECTION_ID}
    tokenId={YOUR_TOKEN_ID}
/>

Attempt to use the CancelListingModal or EditListingModal for an NFT owned by the smart contract wallet account.
Observe that the modal fails to detect the listing due to using the EOA address instead of the smart contract wallet address.

Proposed Solution

Add support for prioritizing the walletClient's accounts over the default account from useAccount. Specifically:

Check if a walletClient is provided and use its active account(s) for modal-related requests.
Fallback to useAccount only if no account is explicitly available from the walletClient.

Impact

This issue makes it impossible to manage listings for smart contract wallets when using a custom walletClient. Considering the growing popularity of smart contract wallets, adding support for this would greatly enhance compatibility and usability.

Let me know if you need any additional information or code snippets to reproduce the issue!