fix: prevent BridgeView from blocking zero-state trending scroll (#28103)

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **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?
-->

Bridge zero-state scrolling could get stuck when a drag started from the
amount area above trending tokens because the outer `BridgeView` wrapper
always claimed the initial responder.

This change keeps the existing blur-and-close behavior for other bridge
states, but lets the scroll view own the gesture when zero-state
trending content is visible so users can scroll naturally into the
trending section.

## **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 bridge zero-state trending scrolling when
dragging from the amount area

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: Bridge zero-state trending scroll

  Scenario: user scrolls into trending tokens from the amount area
    Given I am on the Bridge screen with swaps trending tokens enabled
    And I have not entered a source amount so the zero-state trending section is visible

    When user drags upward starting from the amount area toward the trending section
    Then the Bridge screen should scroll
    And the trending section should continue scrolling without getting stuck

  Scenario: user taps outside the input in non-zero bridge states
    Given I am on the Bridge screen with a positive source amount entered

    When user taps outside the source input area
    Then the source input should blur
    And the keypad should close
```

## **Screenshots/Recordings**

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

### **Before**

N/A

### **After**

N/A

## **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.

## **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.

<!-- Generated with the help of the pr-description AI skill -->

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk UI gesture-handling change limited to the Bridge zero-state
when the trending-tokens flag is enabled; main risk is unintended
responder behavior differences in that specific mode.
> 
> **Overview**
> Prevents `BridgeView`’s outer wrapper from always claiming touch
responder events by making `onStartShouldSetResponder` conditional.
> 
> When the bridge is in **zero-state** and *trending tokens* are
enabled, the wrapper no longer intercepts the initial gesture so the
inner `ScrollView` can scroll normally; all other modes keep the
existing tap-to-blur input and close keypad behavior.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
61a894d. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Author: bfullam

app/components/UI/Bridge/Views/BridgeView/index.tsx

@@ -408,7 +408,9 @@ const BridgeView = () => {
     <ScreenView contentContainerStyle={styles.screen}>
       <Box
         style={styles.content}
-        onStartShouldSetResponder={() => true}
+        onStartShouldSetResponder={() =>
+          !(contentMode === 'zero' && isSwapsTrendingTokensEnabled)
+        }
         onResponderRelease={() => {
           inputRef.current?.blur();
           keypadRef.current?.close();