feat: use outcome property in api requests

[jakubjasinsky]

Summary

Migrate API response handling from the legacy success: boolean property to the new outcome property ("success" | "failed" | "pending"), with backward-compatible fallback. This adds support for the pending payment state across all Dynamic Checkout payment flows.

Changes

Core

• Add resolveOutcome() utility (src/processout/outcome.ts) that reads data.outcome when present, falling back to data.success boolean for backward compatibility
• Replace all 8 !data.success checks in processout.ts with resolveOutcome(data) === OUTCOME.Failed
• Add optional pending callback parameter to makeCardPayment and handleCardActions, threaded through recursive 3DS calls
• When outcome is pending and no pending callback is provided, fall back to success callback for backward compatibility

Dynamic Checkout - Payment Methods

• Add pending handlers to all payment flows: card, saved card, APM, saved APM, Apple Pay, Google Pay
• Remove old pre-payment PAYMENT_PENDING event dispatches (previously fired before makeCardPayment, meaning "in progress") — PAYMENT_PENDING now only fires when the API returns outcome: "pending"
• Fix missing outcome check in apm.ts handleApmPaymentWithSaveForFuture direct apiRequest call (previously had no error handling on the response)
• Add outcome check to handleDeletePaymentMethod in payment methods view
• Fix stray resourceID argument in handleCardActions 3DS1 recursive call (was silently passed as 9th arg, now correctly passes pending)

Views & Locales

• Add DynamicCheckoutPaymentPendingView for displaying pending state to users
• Add payment-pending-message translation to all 9 locales (en, de, es, fr, it, ja, ko, pl, pt)
• Convert pt.ts translations from Brazilian Portuguese (pt-BR) to European Portuguese (pt-PT)

Impact

• Backward compatible: If the API does not include outcome, behavior is identical to before (falls back to success boolean)
• No breaking changes to the public makeCardPayment API — pending is an optional trailing parameter
• Event contract change: PAYMENT_PENDING custom DOM event now fires only on actual pending outcomes, not as a "payment in progress" signal. Consumers relying on the old timing should migrate to PAYMENT_SUBMITTED

Testing Plan

• Verify API responses with outcome: "success" behave identically to previous success: true
• Verify API responses without outcome field fall back to success boolean correctly
• Verify API responses with outcome: "pending" trigger pending callback and show DynamicCheckoutPaymentPendingView
• Verify API responses with outcome: "failed" behave identically to previous success: false
• Test all payment flows: card, saved card, APM redirect, APM save-for-future, saved APM (redirect + direct), Apple Pay, Google Pay
• Test delete payment method flow with outcome check
• Verify PAYMENT_PENDING event only fires on pending outcome, not before makeCardPayment
• Verify pending view renders correctly with showStatusMessage: true and does not render with showStatusMessage: false