refactor(compliance): remove initial block wallets call

[aganglada]

Explanation

This refactor removes the proactive bulk-fetch pattern from ComplianceController and ComplianceService.

Before: On initialisation, init() eagerly fetched the full blocked wallets list from GET /v1/blocked-wallets and persisted all addresses in state.blockedWallets. This meant potentially thousands of OFAC/sanctioned addresses were stored in client state, refreshed on a configurable interval, and used as the primary lookup source for selectIsWalletBlocked.

After: The controller only performs on-demand per-address API checks (checkWalletCompliance / checkWalletsCompliance). Results are cached in walletComplianceStatusMap keyed by address. If a subsequent API call for the same address fails, the cached result is returned as a fallback. If no cached result exists, the error is re-thrown.

Changes

ComplianceController

• Removed state.blockedWallets and state.blockedWalletsLastFetched fields
• Removed init(), updateBlockedWallets(), #isBlockedWalletsStale() and #blockedWalletsRefreshInterval
• checkWalletCompliance and checkWalletsCompliance now wrap the API call in try/catch — on failure they fall back to the per-address cache, re-throwing only when no cached entry exists

ComplianceService

• Removed updateBlockedWallets() method and the GET /v1/blocked-wallets endpoint integration

selectors

• selectIsWalletBlocked now reads solely from walletComplianceStatusMap; the selectBlockedWallets intermediate selector is removed

types

• Removed BlockedWalletsInfo type

Messenger action types / index

• Removed ComplianceControllerInitAction, ComplianceControllerUpdateBlockedWalletsAction, and ComplianceServiceUpdateBlockedWalletsAction

References

N/A

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

High Risk
Breaking public API/state changes remove blocklist fetching and alter selectIsWalletBlocked to depend solely on per-address cached checks, which can change behavior when the API is down. Consumers must update persisted-state migrations and remove calls to deleted controller/service methods.

Overview
Removes the proactive full blocklist fetch/caching flow, shifting compliance to on-demand per-address checks (checkWalletCompliance / checkWalletsCompliance) with a per-address cache used only as a fallback when the API is unavailable.

This is a breaking change: ComplianceControllerState drops blockedWallets/blockedWalletsLastFetched, the controller’s init()/updateBlockedWallets() methods and blockedWalletsRefreshInterval option are removed, and ComplianceService:updateBlockedWallets (and GET /v1/blocked-wallets) plus related exported action/types (BlockedWalletsInfo, init/update action types) are deleted. selectIsWalletBlocked now reads solely from walletComplianceStatusMap, and tests/changelog are updated accordingly.

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

[aganglada]

For reviewers: Doesn't break any existing API as controller is not in production

[mcmire]

Left a comment on the changelog, it's non-blocking though. Everything seems documented so that's what matters :) LGTM.

[mcmire]

Nit: Is this change or the next change breaking? It seems like only the removals would be breaking.

For clarity it might be helpful to split out the removals into their own entries. There is a separate "Removed" category you can use to highlight removals.