fix: ensure that close position screen uses correct decimals

[nickewansmith]

Description

Fixed the decimal precision issue for token amounts displayed in the Perps Close Position screen. The component now uses asset-specific szDecimals from market metadata to format position sizes correctly, ensuring proper display across different cryptocurrencies.

🐛 Problem
Previously, formatPositionSize was called without the szDecimals parameter, causing inconsistent decimal precision across different assets. This resulted in either too many or too few decimal places being displayed for token amounts (e.g., BTC showing too many decimals, DOGE showing unnecessary precision).

✅ Solution
Added usePerpsMarketData hook to fetch market metadata for the position's asset
Passed marketData?.szDecimals to both formatPositionSize calls:
Token amount display in PerpsAmountDisplay component
Token amount in the toggle container text
The formatting now respects asset-specific decimal precision

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/TAT-1922

Manual testing steps

Feature: Position Close Token Amount Formatting

  Background:
    Given the user has an open position
    And the user navigates to the Close Position screen

  Scenario: Display token amounts with asset-specific decimal precision
    Given the position is for <asset> with szDecimals of <decimals>
    When the close amount is calculated
    Then the token amount displays with <decimals> decimal places
    And no unnecessary trailing zeros are shown

  Scenario: Update token display when close percentage changes
    Given the position has specific szDecimals
    When the user adjusts the close percentage slider
    Then the token amount updates in real-time
    And maintains correct decimal precision

  Scenario: Handle missing market data gracefully
    Given the market data is unavailable
    When the close position screen loads
    Then the token amount displays with fallback formatting
    And the component does not crash

  Scenario: Format partial close amounts correctly
    Given the user selects a partial close percentage
    When the token amount is calculated
    Then the display uses asset-specific decimal precision
    And shows accurate fractional token amounts

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• 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 format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). 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.

---

Note

Uses asset-specific szDecimals from market data to format token amounts in Close Position and adds focused tests; minor key fix in error list rendering.

• Perps Close Position (UI):
  • Integrate usePerpsMarketData(position.coin) and pass marketData?.szDecimals to formatPositionSize for tokenAmount and the toggle text.
  • Use stable keys for validation messages (error-${index}).
• Tests:
  • Add comprehensive coverage for szDecimals/market data integration (varying assets/precisions, loading, errors, missing data, small/large sizes) and hook invocation with correct coin.

^{Written by Cursor Bugbot for commit 6ace779. This will update automatically on new commits. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[nickewansmith]

@gambinish this was prev approved but i add sonar cloud updates that were blocking and also unrelated to the PR. Those were mostly removed after the rebase with main just now.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
1 Security Hotspot
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gambinish]

Stamping based on previous approval