fix: error icon ignores color prop due to hardcoded svg fill (TSA-662)

[xavier-brochard]

Description

The Quick Buy failure toast (e.g. "Couldn't sell USDC") showed its leading icon in black instead of the error color. The toast code correctly passes iconColor: theme.colors.error.default, but the shared icon asset app/component-library/components/Icons/Icon/assets/error.svg hardcoded fill="#121314" on its path, which overrides the currentColor mechanism the Icon component relies on. As a result IconName.Error always rendered near-black at every call site (~24 across the app), regardless of the color passed.

This PR removes the hardcoded fill (and the non-standard root fill/width/height attributes) so error.svg matches the structure of the other 283 icon assets and inherits the color passed to Icon. Among all icon assets only error.svg and hash-tag.svg had hardcoded hex fills; hash-tag.svg is left untouched as out of scope.

Note for reviewers: this restores the intended color at every IconName.Error usage app-wide, so visual diffs extend beyond the Quick Buy toast.

Jira: TSA-662

Changelog

CHANGELOG entry: Fixed error icons rendering black instead of the error color (e.g. in the Quick Buy failure toast)

Related issues

Fixes: TSA-662

Manual testing steps

Feature: Error icon color

  Scenario: user sees a Quick Buy failure toast
    Given the user is on a token details page
    And a Quick Buy trade is going to fail terminally

    When the "Couldn't buy/sell" toast appears
    Then the leading error icon is tinted red (theme error color), matching the green icon of the success toast

Screenshots/Recordings

Before

N/A

After

N/A

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 ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[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.