[WIP] refactor: zerion api uses cache-first-datasource

[LucieFaire]

Summary

Refactor network calls in Zerion API services to use CacheFirstDataSource.get() instead of direct network calls with manual caching, aligning with the established pattern used throughout the codebase.

WA-1651

Changes

• ZerionWalletPortfolioApi.getPortfolio() refactored to use dataSource.get()
• ZerionBalancesApi.getBalances() refactored to use dataSource.get()
• ZerionBalancesApi.getCollectibles() refactored to use dataSource.get()
• ZerionBalancesApi._fetchChainMappingForNetwork() refactored to use dataSource.get()
• Rate limiting preserved in ZerionBalancesApi
• All existing tests pass
• No change in external API behavior
• Manual cache logging removed (handled by CacheFirstDataSource)

[LucieFaire]

@claude review

[LucieFaire]

@PooyaRaki
The new path parses cache data as ZerionBalancesSchema ([{ data: [...] }], but the previous implementation wrote only the array ZerionBalanceSchema ([zerionBalances.data]) under the same zerion_balances_<address> cache key/field. So with the new implementation on cache hits it will deserialize to an array and throw ZodError until expiry, causing transient getBalances failures for already-cached wallets.
How critical it is? We can force clean cache for balances, or send a hook event to trigger it. Otherwise we need a fallback here to be able to work with both, but as cache is not long lived i wonder if we should invest in it. WDYT?

[LucieFaire]

I had to extract it above the get call, which now means the cache hits are also counted towards the RL. I can either do a cache pre-check here as it used to be (do double cache lookup), or i can extend datasource.get method to have a .onMiss callback function we can pass. The only thing its not a pattern anywhere else in code.
Not sure if I should just go back to how it was or implement additional stuff
cc @PooyaRaki