…payment token clear and suppress stale balance alert cp-7.73.0 (#28491)

<!--
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**

Fixes two issues in the Predict buy flow when using the
pay-with-any-token feature:

1. Active order state stuck at pay_with_any_token: When the user had
enough predict balance to cover the bet, resetSelectedPaymentToken()
cleared the payment token via setSelectedPaymentToken(null) but never
transitioned the active order state machine from PAY_WITH_ANY_TOKEN back
to PREVIEW. Fixed by routing through selectPaymentToken(null) instead,
which treats null as a balance token selection and properly transitions
the state.
2. Premature insufficient balance alert while typing: The insufficient
pay token balance alert fired while the user was still editing the
amount, because the deposit amount only syncs to
TransactionPayController when the input loses focus. Gated the alert
behind isInputFocused so it only appears after the user finishes
editing.

Changes
- PredictController.selectPaymentToken — Removed the null early-return
guard; null is now treated as balance token (isBalanceToken = true),
triggering the PAY_WITH_ANY_TOKEN → PREVIEW transition
- usePredictPaymentToken.resetSelectedPaymentToken — Calls
selectPaymentToken(null) instead of setSelectedPaymentToken(null)
- usePredictBuyError — Added isInputFocused param to suppress the
insufficient pay token balance alert while the input is focused
- PredictBuyWithAnyToken — Passes isInputFocused through to
usePredictBuyError
- Updated tests for all changes

<!--
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?
-->

## **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: null

## **Related issues**

Fixes: #28492
#28493

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

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

### **Before**

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

### **After**

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

## **Pre-merge author checklist**

- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I've included tests if applicable
- [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] 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.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Touches the Predict buy flow state machine and error handling; small
but user-facing behavior changes could affect order transitions and when
balance errors are shown.
> 
> **Overview**
> Fixes the Predict *pay-with-any-token* buy flow so clearing the
payment token (passing `null`) is treated as selecting Predict balance,
which also resets the active order from `PAY_WITH_ANY_TOKEN` back to
`PREVIEW`.
> 
> Updates `usePredictPaymentToken.resetSelectedPaymentToken` to route
through `selectPaymentToken(null)` (instead of directly setting state),
and adds an `isInputFocused` gate in `usePredictBuyError` to suppress
the insufficient pay-token balance alert while the amount input is being
edited. Tests were updated to cover the new `null` behavior and the
input-focus suppression.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
75fc16f. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->