chore: remove TraderProfileResponse.followingCount

[Bigshmow]

The social-api response contract was changed in social-api PR #88 to drop followingCount (it had been a transitional duplicate of metrics.allPartners.followingCount and is no longer surfaced as a top-level field). The SDK's runtime validation struct still required it, causing fetchTraderProfile to throw FETCH_TRADER_PROFILE_INVALID_RESPONSE and breaking the mobile trader profile view.

Rather than relaxing the field to optional (a half-step that leaves a dead field in the SDK contract), remove it entirely from both the runtime struct and the TypeScript type so the SDK's view of the response matches what the API actually delivers.

Explanation

Current state and why it needs to change

SocialService.fetchTraderProfile runtime-validates each response against TraderProfileResponseStruct using superstruct's is(). The struct asserted followingCount: number() as non-optional, so every response from the updated social-api fails validation. The SDK throws FETCH_TRADER_PROFILE_INVALID_RESPONSE and the mobile view renders its error fallback ("Couldn't load profile") for every trader.

The deeper problem isn't just that the field was required — it's that the field was in the SDK contract at all. The API stopped sending it, no consumer in the MetaMask ecosystem reads it, and the SDK's strict runtime validation surfaced this contract drift as a hard failure rather than gracefully ignoring an unused field.

Solution

Remove followingCount from both TraderProfileResponseStruct and the TraderProfileResponse TS type. After this change, the SDK's view of the trader profile response matches what the API actually delivers, and the struct stops enforcing a contract on a field that has no consumers.

Consumer verification

Before opening this PR, we confirmed that no current consumers across the MetaMask ecosystem read result.followingCount:

• metamask-mobile: zero references in non-test files (grepped).
• Other internal consumers (extension, portfolio, etc.): no references known. Follow-trading on the leaderboard isn't live yet, so even hypothetical consumers wouldn't have shipped a dependency on the field.

If any consumer surfaces an unexpected reference during review, happy to downgrade this to "optional" (minor bump) instead of full removal (major bump).

Why major bump

This is a TypeScript-level breaking change: consumers that read result.followingCount will see a compile error after upgrading. Even though no known consumer does this today, the removal itself is structurally breaking and warrants a major version bump per semver. The release should be tagged 3.0.0.

References

• Triggered by: consensys-vertical-apps/va-mmcx-social-api#88 (dropped followingCount from the trader profile response).
• Downstream: a corresponding mobile PR will follow once this releases, bumping @metamask/social-controllers in metamask-mobile.

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

[Bigshmow]

Reconsidered - followingCount removal from social-api was incidental, not deliberate. Putting the field back in social-api is the cleaner fix. SDK stays as-is.