…ount group and network filter cp-7.77.0 (#29983)

<!--
Please submit this PR as a draft initially.

Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.

In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->

## **Description**

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

Activity’s unified transaction list used the globally selected account
for the Accounts API infinite query (`selectEvmAddress`). When a
**non-EVM** account stayed selected (e.g. Bitcoin) but the network
filter returned to **all popular networks**, the query had no EVM
address and stayed disabled, so the UI showed **only non-EVM** rows.

This PR resolves the query to the **selected account group’s EVM
internal account** when present, falling back to the global EVM address
otherwise. It also **filters confirmed and pending EVM** rows to the
currently **enabled EVM chain IDs** so the list matches the Activity
network filter (including single-chain vs multi-chain). **ConfirmedEvm**
rows use the same **group EVM `selectedAddress`** as pending EVM rows
for consistent decode/display with multichain selection.

This builds on the earlier Activity fixes in
[#29794](#29794)
(TransactionElement / token map); this branch carries the remaining
**UnifiedTransactionsView** and **useTransactionsQuery** alignment.

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: Fixed Activity transaction list not showing EVM history
after switching back from a non-EVM network filter to all popular
networks, and tightened EVM rows to the enabled network filter.

## **Related issues**

Fixes #29952
Refs:  #28035

## **Manual testing steps**

```gherkin
Feature: Activity unified transactions and network filter

  Scenario: EVM history returns when non-EVM account is selected and filter is all popular networks
    Given the user has an account group with both EVM and non-EVM accounts
    And the globally selected account is non-EVM (e.g. Bitcoin)

    When the user opens Activity then sets the network filter to all popular networks

    Then EVM and non-EVM transactions appear in the unified list as expected

  Scenario: Single EVM chain filter only shows that chain
    Given Activity Transactions is open with multiple EVM networks available

    When the user sets the filter to one EVM chain (e.g. Linea) then to another (e.g. Ethereum)

    Then the list updates to transactions for the selected chain only

  Scenario: Pending EVM rows respect enabled chains
    Given the user has a submitted EVM transaction on one chain

    When the user filters Activity to a different single EVM chain

    Then pending rows for other chains do not appear at the top of the list
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

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

### **After**



https://github.com/user-attachments/assets/de557bf5-4caf-4ba2-bcf4-8a4459e53b3d



## **Pre-merge author checklist**

<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.

Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->

- [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
  - Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example

For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).

## **Pre-merge reviewer checklist**

<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->

- [ ] 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]
> **Medium Risk**
> Changes how Activity selects the EVM account/address for history
queries and tightens EVM pending/confirmed filtering by enabled chain
IDs, which can affect transaction visibility in the main Activity list.
> 
> **Overview**
> Fixes unified Activity EVM history loading by resolving the Accounts
API query address from the *selected account group’s* EVM internal
account (falling back to the global `selectEvmAddress`), so EVM activity
still loads when a non-EVM account is selected.
> 
> Aligns the unified list with the network filter by **filtering both
confirmed (API) and pending (local) EVM transactions** to the currently
enabled EVM chain IDs (including guarding against stale paged results),
and ensures confirmed EVM rows pass the same group-based
`selectedAddress` into `TransactionElement` as pending rows.
> 
> Adds targeted tests covering EVM chain-filter behavior for
pending/confirmed rows and the new address-selection precedence rules in
`useTransactionsQuery`.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
67fb3e1. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->