…pay transactions in activity (#30145)

## **Description**

The Activity tab had several bugs causing MetaMask Pay transactions to
be missing, duplicated, or unreachable from the source chain. This PR
addresses four root causes in production code plus a test alignment for
the bridge smoke E2E:

1. **Source-chain visibility.** Submitted EVM transactions were filtered
strictly by `tx.chainId`, so a MetaMask Pay parent was only visible on
its destination chain. The source chain is recorded on
`metamaskPay.chainId` (for gasless flows) or on linked child
transactions via `requiredTransactionIds` (for non-gasless flows). A new
`selectRelatedChainIdsByTransactionId` selector returns the full set of
chain IDs a transaction relates to, and the Activity list now matches
against that set.

2. **Dedupe fallback collapsed internal MetaMask Pay transactions.**
When a transaction had no nonce, `selectLocalTransactions` fell back to
`txParams.actionId` as the dedupe key. `actionId` is a top-level field
on `TransactionMeta`, not on `txParams`, so for MetaMask Pay internal
transactions (which have no nonce) every entry collapsed onto the same
`undefined` key and all but one were dropped. The fallback now uses the
top-level `id`, which is always present.

3. **Local transactions were scoped to the wrong account.**
`selectLocalTransactions` gated on `selectEvmAddress` — the EVM address
of the **currently selected internal account**. When the user picked a
non-EVM account (e.g. Solana), this was `undefined` and the selector
returned an empty list. Switching to "All popular networks" did not
restore the address because that toggle changes enabled networks, not
the selected account. It now uses
`selectSelectedAccountGroupEvmInternalAccount`, the same source already
used by the Activity tab's API query.

4. **Incoming-transaction duplicates.** The `TransactionController`
incoming-transactions feature stores incoming transfers as separate
`TransactionMeta` entries marked with `isTransfer !== undefined`. The
accounts API also returns these transactions in its confirmed history,
producing duplicate rows in the Activity tab. The dedupe step now skips
entries with `isTransfer !== undefined`, leaving the accounts-API row as
the canonical source.

5. **Bridge smoke E2E row alignment.** The Activity list merges pending
smart transactions in alongside the real `TransactionMeta` row,
producing a stale shell entry that lands at row 0. `bridge-action-smoke`
was asserting on row 0 and timing out. The test now asserts on row 1,
with a TODO to remove the STX-state merge from the Activity selectors
and restore row 0.

## **Changelog**

CHANGELOG entry: Fixed MetaMask Pay transactions appearing duplicated or
missing from the Activity tab, including on the source chain and when
the selected account is non-EVM.

## **Related issues**

Fixes:
[#30066](#30066)

## **Manual testing steps**

```gherkin
Feature: MetaMask Pay Activity visibility

  Scenario: User views Activity on the chain that funded a MetaMask Pay transaction
    Given the user has completed a MetaMask Pay transaction funded by a token on chain X with destination chain Y
    And both chains X and Y are enabled networks

    When the user opens the Activity tab with chain X selected
    Then the MetaMask Pay transaction is visible in the list

    When the user opens the Activity tab with chain Y selected
    Then the MetaMask Pay transaction is also visible in the list

  Scenario: User views Activity after switching to a non-EVM account
    Given the user has pending MetaMask Pay transactions visible in the Activity tab

    When the user switches to a non-EVM account in the same account group
    And switches back to "All popular networks"
    Then the pending MetaMask Pay transactions remain visible

  Scenario: User views a single on-chain MetaMask Pay transaction
    Given the user has completed a single-chain MetaMask Pay transaction (for example an mUSD conversion)

    When the user opens the Activity tab
    Then the transaction appears exactly once
```

## **Screenshots/Recordings**

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

#### Performance checks (if applicable)

- [ ] I've tested on Android
- [ ] I've tested with a power user scenario
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> <sup>[Cursor Bugbot](https://cursor.com/bugbot) is generating a
summary for commit f45d17e. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->