[bmc08gt]

Adds seven optional duration properties (ms) to the Add Money event so a Mixpanel dashboard can show which phase of a Coinbase purchase got slower since Solana's Alpenglow upgrade. They're sent only when Method is Coinbase. On a failure, the phases that finished are sent with Total Time and the rest are absent.

Property	Starts	Ends
Order Time	The user confirms the amount	Coinbase returns the placed order
Payment Time	Order placed	Coinbase's onramp_api.payment_authorized event (includes the user's own time on the pay sheet)
Coinbase Time	onramp_api.payment_authorized	Coinbase's onramp_api.polling_success event
Deposit Time	onramp_api.polling_success	The app first sees a nonzero USDC balance in the user's account (includes waiting for Coinbase to send it on-chain)
Swap Time	USDC seen	The USDC to USDF swap returns success
Credit Time	Swap succeeded	The app sees the USDF credited and shows success
Total Time	The user confirms the amount	Add Money is sent, success or failure

iOS needs to match one rule that isn't obvious from the table: when the user is sent to verify a phone number or email first, both clocks restart when they come back and confirm the amount again. Android re-dispatches OnAmountConfirmed after verification, so this falls out of where the timer starts. The rule is in the event description.

Android sender

AddMoneyTimer (shared/tokens, commonMain) holds one monotonic mark per moment and computes the phases. Its TimeSource is injectable, and tests drive it with TestTimeSource. SwapViewModel starts it on amount confirm and reads it in one helper that every Add Money result send now goes through.

Two moments had no outlet before:

• payment_authorized only paused the webview watchdog. It now reaches CoinbaseOnRampController, which emits it and polling_success on a milestones SharedFlow. It isn't a new CoinbaseOnRampState because the handler calls reset() right after Completed, and the conflated StateFlow can skip it.
• UsdcDepositSweep emits UsdcSeen and Swapped on its own milestones flow. It's a singleton that the session's DepositDelegate also starts, so a call from the view model can be a no-op while a session sweep does the work. The view model listens to whichever sweep runs. The timer ignores sweep moments before polling_success, so a sweep of leftover USDC can't count as the deposit.

The generated AddMoneyEvents.result keeps its four leading parameters, so existing callers compile unchanged. AddMoneyEventsTest.resultIsTheEventNamedAddMoney is untouched. SwapViewModelErrorTest asserts the whole event for a full Coinbase success, a delivery failure (Order/Payment/Coinbase/Total only), and a Phantom deposit with no phase properties.

The controller's onPaymentAuthorized only has a negative test (no emit outside a payment). Getting to Paying there needs the JWT and order stubs. CoinbaseOnRampEventHandlerTest covers the webview event reaching the callback.

Catalogue descriptions

Token Purchase With {method}, Onramp: {step} and Create Account Payment drop the "Android only; part 2 decides whether iOS sends it" wording, because iOS sends all three (a parallel iOS PR is wiring them). Create Account Payment now says it's the account-creation payment, distinct from Create Account at registration. Drift notes are unchanged.

Follow-up

The direct launchpad-token buy through Coinbase is out of scope. addMoneyMethod is null when the mint isn't USDF, so that path sends no Add Money and no phase times.