Description

Fixes collapsed Predict market detail action buttons for single-outcome markets. The Yes/No footer actions were rendering as visible controls, but their parent action columns could measure too small, which made the footer border appear in the wrong place and left the buttons visually clipped.

This change reserves the expected action button height in the Predict market details action columns while preserving the existing showPayoutEstimate layout behavior. It also adjusts the fee exemption label positioning so it remains anchored with the footer layout.

Changelog

CHANGELOG entry: Fixed a bug that caused Predict market action buttons to appear collapsed on single-outcome market details.

Related issues

Fixes: PRED-926 https://consensyssoftware.atlassian.net/browse/PRED-926?atlOrigin=eyJpIjoiOWEwZDE0N2ZhZTZlNGYwNzk5NGI3OTFkZGQyNDFkNjgiLCJwIjoiaiJ9

Manual testing steps

Feature: Predict market details footer actions

  Scenario: single-outcome market details show Yes and No actions
    Given the user opens an open Predict market details screen for a single-outcome market
    And the market has Yes and No outcome tokens

    When the market details screen finishes loading
    Then the Yes and No footer action buttons are fully visible
    And the footer border is positioned above the full action area
    And existing position content remains visible above the footer

Screenshots/Recordings

Before

Yes/No footer action buttons appeared collapsed, with only a thin strip visible and the footer border positioned through the action area.

After

Yes/No footer action buttons are fully visible at the bottom of the market details screen.

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.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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 tic