feat: augment runtime LP tokens metadata from Portals

[gomesalexandre]

Description

Rationale: While attempting to tackle #730, I noticed Zapper was already giving us the LP tokens data we need, and all we needed was to route using isPool criteria.
Easy? As it usually goes, not exactly. After debugging things out and accomodating the Zapper parser with its parsing, I noticed the routing still wasn't working for some assets, but was working for others. The reason for that is if we are missing an asset in generatedAssetData.json (which we may), but have it in the portfolio, we'll leverage unchained to upsert its minimal version - minimal in this context meaning on-chain symbol, name, etc. No image, nothing fancy.

This PR ensures we leverage Portals data for said assets whenever possible, in preparation for the actual routing in a follow-up.

Issue (if applicable)

• contributes to Portals - LP Tokens as DeFi Positions  #7304

Risk

High Risk PRs Require 2 approvals

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

Testing

This one assumes you have some LP tokens which are not present in the current Portals assets in the store. I tested this myself with Trader Joe BNB/AVAX i.e 0xeb8eb6300c53c3addbb7382ff6c6fbc4165b0742

• Ensure asset icons look sane for pool assets that are not present in generatedAssetData.json
• Ensure asset name looks sane and follows our LP terminology

Engineering

Operations

• 🏁 My feature is behind a flag and doesn't require operations testing (yet)

Screenshots (if applicable)

Tested against develop (right):

[kaladinlight]

removed select asset from generated assets and confirmed detection and asset upsert on load and via websocket.

approving in knowing there will be a follow up to further cleanup any duplication, align logic in src/lib/portals and update to react query as required for markets page.