Description

This PR implements critical edge case handling for perpetual trading (JIRA TAT-1280) while
establishing a robust protocol-agnostic architecture. The key achievement is moving all
validation logic from the UI layer to the protocol provider level, ensuring that
protocol-specific rules are properly encapsulated and maintainable.

Key improvements:

1. Protocol-agnostic architecture: All validation logic now resides at the provider level
   (HyperLiquidProvider), not in UI components
2. Async validation infrastructure: Made all validation methods async to enable real-time,
   protocol-specific validation
3. Fixed critical edge cases:
   • Proper USD value calculation from coin amounts (was comparing apples to oranges)
   • Asset-specific leverage limits (e.g., 3x for some assets, 50x for others)
   • Partial position close validation to prevent positions below minimum tradeable size
   • Removed incorrect maximum order size validation (HyperLiquid has no fixed max)

The architecture now supports easy addition of new protocols without touching UI code - just
implement the IPerpsProvider interface.

Changelog

CHANGELOG entry: Fixed perpetual trading edge cases and improved protocol-agnostic validation
architecture to properly enforce minimum order sizes and asset-specific limits

Related issues

Fixes: TAT-1280

Manual testing steps

1. Navigate to the Perps trading interface
2. Select any trading pair (e.g., BTC-USD)
3. Try to place an order below the minimum amount ($10 mainnet, $11 testnet) - should show
   validation error
4. Try to set leverage above the asset's maximum (varies by asset) - should show validation
   error with correct max
5. Open a position and try to partially close it
6. Verify that partial close is prevented if remaining position would be below minimum order
   size
7. Switch between different assets and verify each has its own leverage limits
8. Verify all validation messages appear immediately without delay

Screenshots/Recordings

Before

• Validation logic scattered across UI components
• Used hardcoded leverage limits (20x for all assets)
• Minimum order validation incorrectly compared coin amounts to USD values
• No validation for partial position closes
• Deprecated validation functions in utils

After

• All validation logic centralized in protocol providers
• Asset-specific leverage limits properly enforced
• Correct USD value calculation for minimum order validation
• Partial close validation ensures remaining position meets minimums
• Clean, protocol-agnostic architecture

Pre-merge author checklist

• I've followed MetaMask Contributor Docs
  and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.g ithub/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 format if applicable
• I've applied the right labels on the PR (see [labeling guidelines](https://github.com/Met
  aMask/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.