chore(runway): cherry-pick fix(perps): correct amount reset when balance changes and simplify setAmount cp-7.65.0 (#25776)

- fix(perps): correct amount reset when balance changes and simplify
setAmount cp-7.65.0 (#25759)

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

1. **What is the reason for the change?**  
When the user changed the payment token or when the effective balance
dropped, the Perps order form was resetting the amount to max whenever
the current amount was greater than the new max. That logic could also
run when the user had intentionally set the amount to 0 or left it empty
(e.g. initial value 10), and `setAmount` was forcing empty values to
`'0'`, which made it harder to preserve the intended initial amount.

2. **What is the improvement/solution?**  
- In the `useEffect` that reacts to `balanceForMax` /
`maxPossibleAmount` / `orderForm.amount`: only reset the amount when it
actually exceeds the new max. If `currentAmount === 0`,
`maxPossibleAmount === 0`, or `currentAmount < maxPossibleAmount`, we
return early and do not overwrite the form amount.
- In `setAmount`, pass through the `amount` string as-is and remove the
`|| '0'` fallback so the form can keep an empty or user-chosen initial
value (e.g. 10) without being forced to `'0'`.


## **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 Perps order form so the amount is only reset when
it exceeds the new max after changing payment token or balance, and no
longer overwrites an initial or empty amount.

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: Perps order form amount when balance or payment token changes

  Scenario: user has set amount to 10 and then changes payment token
    Given user is on the Perps order view with amount set to 10 (or another value below the new max)

    When user changes the payment token (or balance updates so max possible amount changes)
    Then the amount remains 10 and is not reset to max or to 0
```

## **Screenshots/Recordings**


### **Before**

No visible change

### **After**

No visible change

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

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Small, localized UI state change to Perps order form amount clamping
with minimal surface area; main risk is behavior differences around edge
cases like `0`/empty amounts.
> 
> **Overview**
> Fixes Perps order form amount clamping when
`balanceForMax`/`maxPossibleAmount` changes so it only overwrites the
entered amount when the current value is **greater than or equal to**
the new max, and avoids clamping when either value is `0`.
> 
> This refactors the `useEffect` to early-return for non-exceeding/zero
cases and consistently floor the recalculated max before updating
`orderForm.amount`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
68bf99e. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
[985f421](985f421)

Co-authored-by: Michal Szorad <michal.szorad@consensys.net>
Co-authored-by: Cursor <cursoragent@cursor.com>

Author: 3 people

app/components/UI/Perps/hooks/usePerpsOrderForm.ts

@@ -250,13 +250,19 @@ export function usePerpsOrderForm(
 
   // When user changes payment token (or effective balance drops), reset amount to MAX if current amount exceeds new max
   useEffect(() => {
-    const current = Number.parseFloat(orderForm.amount || '0');
-    if (maxPossibleAmount >= 0 && current > maxPossibleAmount) {
-      setOrderForm((prev) => ({
-        ...prev,
-        amount: String(Math.floor(maxPossibleAmount)),
-      }));
-    }
+    const currentAmount = Number.parseFloat(orderForm.amount);
+    if (
+      currentAmount === 0 ||
+      maxPossibleAmount === 0 ||
+      currentAmount < maxPossibleAmount
+    )
+      return;
+    const newValue = String(Math.floor(maxPossibleAmount));
+
+    setOrderForm((prev) => ({
+      ...prev,
+      amount: newValue,
+    }));
   }, [balanceForMax, maxPossibleAmount, orderForm.amount]);
 
   // Update entire form