feat: improve chomp upgrade process

[Jwhiles]

PR: GET-first address association for the Money Account upgrade flow

Repos: MetaMask/core → metamask-mobile (adoption to follow)
Packages: @metamask/chomp-api-service (breaking → 4.0.0), @metamask/money-account-upgrade-controller (breaking → 3.0.0)

Explanation

The associate-address step of the Money Account upgrade flow currently signs a
CHOMP Authentication message and POSTs it to /v1/auth/address on every run,
relying on the response to discover that the address was already associated. That
means a keyring signing operation happens even when there is nothing to do.

This PR makes the step check first and sign only when needed:

• @metamask/chomp-api-service: adds getAssociatedAddresses()
  (GET /v1/auth/address), which returns the authenticated profile's active
  address associations. Results are parsed into canonical form (lowercased
  addresses, status guaranteed 'active') and are never served from cache,
  since the response is scoped to the authenticated profile and consumers use it
  to decide whether to sign.
• @metamask/money-account-upgrade-controller: the associate-address step
  now calls the new action first and reports already-done — without touching
  the keyring — when the address is already associated. The lookup is an
  optimization: if it fails, the step falls through to the previous
  sign-and-submit behaviour.

While verifying the endpoint's semantics against the CHOMP API source, I found
that the existing 409 handling was wrong. CHOMP returns
201 + status: 'active' when the address is already associated with the
authenticated profile; a 409 means the address is associated with a
different profile (or, rarely, that two same-profile requests raced on the
initial create). The old code treated 409 as a success case and tried to parse
its error body as an association result, which would have failed with a
confusing validation error. Now:

• associateAddress throws an HttpError on any non-OK response (breaking).
• The step disambiguates a 409 by re-fetching the associations: a same-profile
  race resolves to already-done; a genuine cross-profile conflict fails the
  step with a clear error.

The controller change is breaking because MoneyAccountUpgradeControllerMessenger
consumers must now grant ChompApiService:getAssociatedAddresses and pair it
with @metamask/chomp-api-service >= 4.0.0.

References

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