feat: Add fiatPayment into transactionData

[OGPoyraz]

Explanation

Adds fiatPayment state to TransactionPayController and introduces an atomic updateFiatPayment API with incremental patch semantics.

TransactionData now includes fiatPayment (selectedPaymentMethodId, amount, quickBuyOrderId), the new TransactionPayController:updateFiatPayment action is registered and exported, and transaction initialization/reset paths now consistently default fiat fields to null (including reset on payment-token changes).

References

• Fixes https://github.com/MetaMask/MetaMask-planning/issues/7070

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Introduces a new persisted-in-memory state field (transactionData.fiatPayment) and a new messenger action; downstream consumers relying on the previous TransactionData shape or payment-token update behavior may need adjustments.

Overview
Adds a new per-transaction fiatPayment state object to TransactionPayController (typed as TransactionFiatPayment) and exports/registers a new TransactionPayController:updateFiatPayment messenger action for callback-based, incremental updates.

Ensures fiatPayment is initialized for new transactions and is reset to {} when updatePaymentToken runs, with new unit tests covering the action behavior, messenger wiring, and the new default state shape; updates the package changelog accordingly.

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

[matthewwalsh0]

As we don't persist, should we instead store transactionId in the Ramps state?

[OGPoyraz]

I agree storing transactionId in Ramps state is better solution. We should raise this on upcoming meeting.

But not fully sure the concern of state persistence. If we are thinking of incomplete transactions, those will be cleanup on initialization we will never be able complete the transaction anyway.

Are you thinking of combining Ramp activity later in the "transaction activity"?

[matthewwalsh0]

True, but the hope is we can infer the original intent later by looking at the old failed transaction.

But that's a future concern, for now do we need quickBuyOrderId here?

We will have the quotes in state in whatever format the strategy wants, so could that include any IDs we need?

[OGPoyraz]

We will have the quotes in state in whatever format the strategy wants, so could that include any IDs we need?

OrderId only created when user completed the checkout flow, so it's not tied to quote.

But I get your point, it's not needed right now removed it. Hope Ramps can let us inject TransactionController id and we don't have to put this back.

[matthewwalsh0]

True, but the hope is we can infer the original intent later by looking at the old failed transaction.

But that's a future concern, for now do we need quickBuyOrderId here?

We will have the quotes in state in whatever format the strategy wants, so could that include any IDs we need?

[matthewwalsh0]

Apologies, I was meaning could the updateFiatPayment action itself, accept a callback so the clients can specify a callback to mutate specific values?

Like how updateTransactionConfig accepts a callback?

[OGPoyraz]

Updated this way.