feat(client-utils): map Stellar trustline keyring transactions

[jeremytsng]

Explanation

@metamask/client-utils's mapKeyringTransaction (#9376) doesn't yet handle Stellar trustline TokenApprove/TokenDisapprove transactions — they fall through to approveSpendingCap/contractInteraction like any other token approval, which shows a spending-cap UI for what's actually a trustline activation/deactivation (not a token transfer).

metamask-extension#44200 added this mapping locally in its own adapter ahead of Core support, keyed off a details.typeLabel of trustline-approve/trustline-disapprove. This PR ports that mapping into the canonical keyring-transaction-mapper so Extension can switch over to it, per review discussion on that PR.

Changes:

• Add assetActivation/assetDeactivation to ActivityKind and a matching
  ActivityItem data shape ({ from?, token?, fees? }).
• Port CustomTransactionTypeLabel and hasTrustlineTypeLabel from the extension adapter.
• TokenApprove now branches to assetActivation for trustline ops before falling into the existing approveSpendingCap logic.
• Add a TokenDisapprove case (previously unhandled — fell through to contractInteraction via default): branches to assetDeactivation for trustline
  ops, otherwise keeps the existing contractInteraction fallback.
• Trustline items clear the token amount (matching the spending-cap "unlimited" pattern) since a trustline change isn't a token transfer and shouldn't show a total.

References

• Follow-up to feat(client-utils): add activity mappers #9376, which added mapKeyringTransaction.
• Ports the mapping from metamask-extension#44200.
• Requested here: metamask-extension#44200 (review thread)

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

Low Risk
Scoped mapper and type additions with tests; non-trustline approve/disapprove behavior is unchanged aside from an explicit TokenDisapprove path that still falls back to contractInteraction.

Overview
mapKeyringTransaction now recognizes Stellar trustline operations via details.typeLabel (trustline-approve / trustline-disapprove) instead of treating them like generic token approvals.

TokenApprove with a trustline label maps to assetActivation (token amount cleared so the UI does not show a transfer total). TokenDisapprove gets an explicit branch: trustline → assetDeactivation, otherwise contractInteraction as before.

Shared types add assetActivation and assetDeactivation to ActivityKind and ActivityItem. CustomTransactionTypeLabel and hasTrustlineTypeLabel are exported from the keyring mapper (ported from extension). Tests and changelog updated.

^{Reviewed by Cursor Bugbot for commit dc50e53. Bugbot is set up for automated code reviews on this repo. Configure here.}

[stanleyyconsensys]

Plz change the PR title to skip stellar
it doesnt have to be stellar, xrpl (the next non evm) using trustline to

[stanleyyconsensys]

LGTM