[Fix] incorrect network info on NFT sends + L2 explainer sheet

[BrodyHughes]

Fixes BX-1688

What changed (plus any additional context for devs)

We had user reports that NFT sends on base in the BX are showing the wrong network message during the send process. I could reproduce this behavior. We were just defaulting to mainnet because our current logic was relying on asset.chainId which was returning undefined. this is expected behavior because our NFT data comes from nft not asset

The fix was to instead use our more broad chain info found in our chain object. This is defined as:

  const assetChainId =
    asset?.chainId || chainNameToIdMapping[nft?.network || ChainName.mainnet];
  const chain = useMemo(
    () => chains.find((c) => c.id === assetChainId),
    [assetChainId, chains],
  );

Using the chain object for chain related info returns the correct data for both token AND nft sends as you can see in my POW.

Another bug i fixed here was related to L2 explainers. The same issue we had with the above info was making L2 explainers not show at all on NFT sends, so I moved that logic over to chain as well for its info.

Screen recordings / screenshots

POW:

Screen.Recording.2025-01-14.at.2.47.16.PM.mov

What to test

Do sends of NFT and tokens on L2 networks and make sure the review sheet shows the correct info.

[linear]

BX-1688 Incorrect network message for NFT sends

[walmat]

this doesn't need to be optionally chained if you're null checking beforehand. Also, any way to avoid having to cast as ChainId? I kinda hate this pattern of casting number -> ChainId

[BrodyHughes]

yes. will fix this up later today.

[DanielSinclair]

@BrodyHughes Not familiar with the upstream queries, but I wonder if we can also deprecate the || ChainId.mainnet fallbacks since they caused the issue initially. That way the type errors give tell us something useful. It looks the network param is also added manually to UniqueAsset here, so we could do the string->id translation upstream there (matching the asset chain type) to avoid having to ever use the chain name string here

[BrodyHughes]

@BrodyHughes Not familiar with the upstream queries, but I wonder if we can also deprecate the || ChainId.mainnet fallbacks since they caused the issue initially. That way the type errors give tell us something useful. It looks the network param is also added manually to UniqueAsset here, so we could do the string->id translation upstream there (matching the asset chain type) to avoid having to ever use the chain name string here

Yo lemme know if i am misunderstanding but i checked the upstream code and saw that we're already handling the chain conversion in simpleHashNFTToUniqueAsset where the NFT data is first processed. The chain?.id undefined check is happening separately in the UI layer, so removing the mainnet fallback wouldn't solve our current type issue i dont think

[DanielSinclair]

Tested NFT and ERC20 send reviews on Mainnet and Base