chore: remove hardcoded NFT chain allowlist from NftDetectionController

[juanmigdr]

Explanation

Summary

As part of the NFT provider migration plan, this PR removes the hardcoded supportedNftDetectionNetworks allowlist from NftDetectionController and delegates chain support validation to the server instead.

Deployment dependency: This PR depends on backend changes deployed to production in va-mmcx-nft-api#221. Do not merge this PR until those backend changes are live in production. The server must return an empty array (instead of an error) for unsupported chains before the client-side chain gating can be safely removed.

Changes

• Remove supportedNftDetectionNetworks: Drops the static Set<Hex> that previously allowed only 8 specific chains (Mainnet, BSC, Polygon, Avalanche, Linea, Base, Sei, Monad) through NFT detection. Detection now passes all provided chain IDs directly to the API.
• Remove chain filtering in detectNfts: The pre-API filter that dropped unsupported chains before calling #getOwnerNfts has been removed. chainIds is now passed through unmodified, allowing the server to decide what to return.
• Add non-EVM guard in #getOwnerNfts: Chains that convert to decimal '0' (non-EVM/invalid chains) are filtered out before making the API call, and if all chains are non-EVM, the method returns { tokens: [], continuation: null } early — avoiding a pointless API round-trip.
• Fix continuation type: Updated ReservoirResponse.continuation from string | undefined to string | null to match the updated server response shape.

Motivation

Keeping a hardcoded chain allowlist in the Core package tightly coupled backend and frontend release cycles — adding support for a new chain required coordinated changes in both places simultaneously. The backend change in va-mmcx-nft-api#221 updates the NFT API to return [] instead of an error for unsupported chains. With that in place, the Core package no longer needs to know which chains are supported, enabling each side to evolve independently going forward.

Testing

• All existing NftDetectionController tests should continue to pass.
• Verify that NFT detection on previously unsupported chains gracefully returns no results rather than throwing.
• Verify that non-EVM chains short-circuit before hitting the API.

Merge checklist

• va-mmcx-nft-api#221 is merged and deployed to production
• NFT detection verified end-to-end against production API on at least one previously unsupported chain

References

https://consensyssoftware.atlassian.net/browse/ASSETS-2899

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Behavior now depends on the backend returning empty results (not errors) for unsupported chains, and changes request scoping/filtering for multi-chain NFT detection.

Overview
NftDetectionController no longer hardcodes a supportedNftDetectionNetworks allowlist; detectNfts now sends whatever chainIds it’s given to the NFT API (relying on the server to return empty results for unsupported chains).

To avoid pointless requests, #getOwnerNfts now filters out non-EVM chain IDs (hex that convert to decimal 0) and short-circuits with an empty { tokens: [], continuation: null } response when nothing remains. The ReservoirResponse.continuation type is updated to string | null to match the API response shape, and the changelog is updated accordingly.

^{Written by Cursor Bugbot for commit 1be56af. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}