fix(perps): [Bug]: Perps - Error when selecting imported account ApiRequestError: Multi-sig required

[abretonc7s]

Explanation

Opening the Perps tab with a HyperLiquid multi-sig account raised
ApiRequestError: Multi-sig required, on every entry.

Perps initialization runs HyperLiquidProvider.#ensureUnifiedAccountEnabled,
which migrates an account on a legacy abstraction mode to unifiedAccount. For
default / disabled accounts that is a silent agent-signed
agentSetAbstraction write. HyperLiquid rejects every single-signer
exchange write for an account that has been converted to multi-sig, so this
write could never succeed — but nothing classified the account shape before the
write, and nothing classified the rejection after it. It fell through to the
generic failure handler, which caches nothing, sets the retry flag (so
#ensureReady drops its memoized promise), and reports the error. The result
was a permanent error for these accounts and recurring Sentry noise.

Two changes:

• HyperLiquidProvider now reads infoClient.userToMultiSigSigners immediately
  before the migration write. For a multi-sig account it skips the write, emits
  Perp Account Setup with status: not_applicable /
  error_message: multi_sig_account, and records
  { attempted: true, enabled: false } in TradingReadinessCache — a final
  state, so the attempt is not repeated. The lookup only runs when a migration
  write would otherwise be made, so accounts already on unifiedAccount /
  portfolioMargin, deferred dexAbstraction accounts (including hardware
  wallets at init) and unknown modes pay no extra round trip. The probe fails
  open on a transient info-API error, so it can never block migration for a
  normal single-signer account.
• The new isHyperLiquidMultiSigRequiredError classifier (exported from
  @metamask/perps-controller/utils/*) is applied in the same method's catch,
  covering the case where the account is converted between the lookup and the
  write, and the case where the probe failed open. It matches case-insensitively
  and accepts both multi-sig required and multisig required; only the
  hyphenated form has been observed in the wild (the ticket, and the mapping
  added in fix(perps): harden HyperLiquid cancel readiness and map account-mode errors #9750), so the unhyphenated variant is defensive rather than
  documented venue behaviour.

Unified account mode stays off for these accounts by design; HIP-3 collateral
continues through the existing programmatic transfer fallback. Behaviour for
single-signer accounts is unchanged apart from the one pre-write lookup.

Note for a follow-up (out of scope here): the other user-scoped exchange writes
reached from #ensureReadyForTrading — approveBuilderFee and setReferrer —
will hit the same rejection at trade time for these accounts, and
#setReferralCode still routes it to the error logger.

How this was verified

Reproduced and fixed against a real HyperLiquid account. A testnet account
was transiently converted to multi-sig and the real PerpsController was driven
through #ensureReady → #ensureUnifiedAccountEnabled from two isolated
checkouts. Only the checked-out source differed:

Run	Multi-sig required logged	Unified Account setup failed	migration skipped
main	yes	yes	no
this branch	no	no	yes

Baseline logged Unified Account setup failed {…,"error":"Multi-sig required"}
and forwarded it to the error logger — the reported bug. This branch logged
Multi-sig account, skipping unified account migration {…,"mode":"default"} and
raised no error. The account was restored afterwards (signer set null,
abstraction default, funds returned) and verified against its pre-mutation
snapshot. Testnet only; no order was placed, cancelled or edited.

Unit regression net (independently diff-sensitive). Reverting only
HyperLiquidProvider.ts and errorUtils.ts, leaving the tests in place, fails
exactly three assertions of 60 — the migration skip, the readiness-cache state,
and logger.error receiving 1 call where 0 is expected — and passes again when
restored. The classifier target fails separately with
isHyperLiquidMultiSigRequiredError is not a function.

Live mainnet read path (getAccountState / getPositions, read-only) was
also exercised to confirm no regression to controller initialization and reads.
That tier is explicitly not diff-sensitive for this change and is not offered
as evidence for the fix.

Remaining limitation: the multi-sig runs are captured artifacts rather than a
replayable recipe step, because restoring the account to single-sig is the
required end state. A repeatable version needs a permanently multi-sig testnet
fixture account and a read-only ensure-ready action in the harness.

Relationship to #9750

#9750 (TAT-3633, now merged) maps
the same HyperLiquid rejection to a typed EXCHANGE_MULTI_SIG_REQUIRED code on
the order and cancel paths. This PR stops the account-setup write from being
attempted at all, which is what produces the error on Perps tab entry. The two
are complementary and neither subsumes the other.

HyperLiquidProvider.ts auto-merges cleanly — that PR touches ~511, 2393,
3439–3463, 3711, 3737, 4061–4096, this one 136, 785, 980, 1075 — and the test
files are disjoint. packages/perps-controller/CHANGELOG.md does conflict
now that #9750 has merged: both add entries to the same Unreleased sections.
git merge-tree --write-tree against current main reports
CONFLICT (content) on that file alone. It needs a trivial resolution (keep
both sets of entries) before merge.

Optional follow-up for whichever merges second: #mapError's static table keys
only on 'multi-sig required', while the classifier added here also matches the
unhyphenated spelling. #mapError already calls isHyperLiquidUserNotFoundError
as a function for the analogous EXCHANGE_ACCOUNT_NOT_FOUND case, so
isHyperLiquidMultiSigRequiredError could be reused there instead of keeping two
matchers. Not a blocker for either PR.

The blocking review comment on #9750 about a dropped cancel status error is a
separate cancelOrder response-shape issue and does not affect this change.

References

• Fixes TAT-3214
• Replaces the closed Mobile Yarn patch fix(perps): [Bug]: Perps - Error when selecting imported account ApiRequestError: Multi-sig required metamask-mobile#34170, which
  demonstrated the behaviour but belongs in @metamask/perps-controller. No
  Mobile dependency bump is included here; Mobile picks this up through a normal
  release.
• Related: fix(perps): harden HyperLiquid cancel readiness and map account-mode errors #9750 (TAT-3633, merged) maps the same HyperLiquid
  rejection on the order/cancel paths. Complementary surfaces; this branch
  auto-merges against main with no textual conflicts.

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

Screenshots/Recordings

LIVE diff-sensitive Core proof for TAT-3214. A HyperLiquid TESTNET account (dev3) was transiently converted to multi-sig and the real PerpsController was driven through #ensureReady -> #ensureUnifiedAccountEnabled from two isolated checkouts: origin/main logged the genuine 'Multi-sig required' rejection, this branch skipped the write. The account was restored and verified against its pre-mutation snapshot (signers null, mode default, funds returned). Supporting tiers: live mainnet read-only non-regression, and a re-runnable unit regression net. No mainnet mutation, no trading, no visual evidence.