Add googlePay shipping address & shipping options collection

[ana-maksimovskikh]

External docs update: https://github.com/evervault/docs/pull/868

Adds to Google Pay Android (the missing piece vs Apple Pay and Google Pay web (ticket)).

• shipping address collection
• a shipping option picker
• live total recompute

What's new

• Config.shippingAddress / Transaction.shippingOptions — opt in to address collection and offer a fixed shipping-option list.
• Config.googlePayShipping + GooglePayShippingHandler — invoked on every address/option change in the sheet; can accept (with a recomputed total) or reject the current selection.
• TokenResponse.shippingAddress / .shippingOption on the final result.
• Demo app: ENABLE_GOOGLE_PAY_SHIPPING=true wires up a sample handler demonstrating destination-based rejection and pricing.

Design choice: fixed option list, not dynamic

A handler can recompute the total per destination but can't add/remove/reprice options in the list itself.
Matches Apple Pay web, Apple Pay iOS, and the still-unbuilt Google Pay web sibling ticket (CARD-1057).
Filed CARD-1235 to track a fully dynamic list as a future decision.

Worth flagging in review

• Amount.format() went internal → public: it's the only way a merchant's handler (a separate module) can read an amount to compute a new total.
• Option labels are sent to Google Pay exactly as given. No price field exists on Google's side, so baking a price in (or leaving it out, if the rate varies by destination) is the merchant's call. See ShippingOption.label.
• Fixed a pre-existing-shaped bug in extractPaymentShippingAddress: Gson deserialized Google Pay's "" for inapplicable fields (e.g. no address2 in Japan) straight through instead of null.

Verified

• Unit tests: PaymentRequestTest, GooglePayShippingTest, PaymentDataTest, GooglePayResponseParityTest.
• Manual, against a real Google Pay sandbox: live total updates, shipping + inline authorization composing in one sheet, reject/retry preserving the prior selection, and address-based reject/reprice.

[Max Harrison (maxharrison)]

Hey I’ve implemented the equivalent Google Pay web shipping work in evervault-js #1006. I used this PR as refernce for the same core model but still keeping the web API idiomatic to js.

The web callback contract is defined here. The sheet state and dynamic update handling are implemented here.

These are some things the impls share:

- A selected `ShippingOption`, including an optional amount on web.
- The current address, selected option, total, line items, and options during callbacks.
- Explicit success or error results.
- A 10-second callback timeout.
- The full selected shipping option in the final payment result.

But I think here are a few things we can do to align this android PR (happy to talk through it when you're back too):

1. Make Android Accept a partial update. total, lineItems, and shippingOptions could be optional. Omitted fields would retain their current values.
2. Let Android callbacks replace the shipping-option list. This supports destination-specific options, such as removing express delivery for remote addresses.
3. Add the callback trigger to GooglePayShippingUpdateRequest.
4. Apply the same option validation on both platforms: non-empty lists, non-empty IDs and labels, unique IDs, and a valid default ID.
5. Make shipping options enable address collection on Android too, unless option-only checkout is an intentional Android capability.

This would be good so the customer-visible behaviour and data model match, but each SDK kept idiomatic.