fix(ramps-controller): compare internal order ids during order processing

[amitabh94]

Summary

Fixes duplicate fiat-on-ramp Activity rows (TRAM-3539) when redirect providers (Moonpay, PayPal, Coinbase, etc.) return a provider-native id in providerOrderId while the precreated stub used MetaMask's internal order code (c-{guid}).

Root cause: RampsController merged orders on providerOrderId. After precreate, stub and API/callback updates often disagree on that field even though they represent the same buy.

Fix: Introduce getInternalOrderCode() to derive the canonical code from order.id (/providers/{provider}/orders/{code}), then merge/heal in addOrder, getOrder, and addPrecreatedOrder on that key. Stored providerOrderId is normalized to the internal code so polling continues to use c-{guid} (supported by on-ramp-api → Moonpay /v1/transactions/ext/{code}).

Changes

• Export getInternalOrderCode() from @metamask/ramps-controller
• Merge orders by internal order code, not provider-native providerOrderId
• Regression test: precreated stub + API order with mismatched providerOrderId → single merged row
• Changelog entry under [Unreleased] → Fixed

Out of scope

• No on-ramp-api changes (BE already resolves Moonpay orders by internal c- code)
• Mobile follow-up: bump @metamask/ramps-controller after release + Moonpay buy QA

Test plan

• yarn workspace @metamask/ramps-controller run jest packages/ramps-controller/src/RampsController.test.ts (285 tests)
• After mobile picks up release: Moonpay redirect buy → one Activity row, amounts populate after completion

Fixes TRAM-3539

[amitabh94]

@metamaskbot publish-previews

[amitabh94]

Superseded by upstream branch PR #9159 (enables preview builds and CI).