fix: scope keyring send token to subject address

[n3ps]

Explanation

Non-EVM keyring sends (especially Solana bridge source legs) often include movements for many parties. mapKeyringTransaction previously took the first movement in from.

When subjectAddress is provided, Send mapping now filters from to that address before selecting the token.

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

---

Note

Low Risk
Narrow change to activity display mapping for Send when subjectAddress is provided; no auth, persistence, or transaction execution impact.

Overview
Fixes incorrect send activity for multi-party keyring transactions (notably Solana bridge source legs) where activity showed another address’s token because mapping used the first from movement.

When subjectAddress is passed into mapKeyringTransaction, Send mapping now filters from to that address before choosing the outbound fungible token, so the listed asset matches what the user actually sent (e.g. SOL instead of a counterparty’s USDC). Behavior without subjectAddress is unchanged; Bitcoin’s to-side fallback is untouched.

Adds a Solana bridge fixture and regression test, plus an Unreleased changelog entry under Fixed.

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

[n3ps]

Point of interest