feat(checkout): CHECKOUT-10026 Connect new Google Places API behind feature flag

[bc-maxy]

What/Why?

This is part II of this change: #3135, where I actually wire up this new Places API service to production, but hide new functionality behind a feature flag.

When the CHECKOUT-10026.new_google_places_api experiment is on, address autocomplete uses Google's new Places API (session-token based, AutocompleteSuggestion/Place classes) instead of the legacy API service. If the new API is denied due to permissions error (gRPC PERMISSION_DENIED), we assume that the service is not enabled for the store and silently fall back to the legacy API for the rest of the session. No visible errors for users and no visible change between old and new service - this is an infrastructure swap behind a feature flag.

NOTE: when the flag is off, there will be no change for end users, However, the code won't be byte-to-byte identical: we initialize newGooglePlacesApiServiceRef.current with new NewGooglePlacesApiService(apiKey) unconditionally on mount, even when the flag is off. It has no side effects though (no network call, no script load - the script loader inside of it is lazy), so this is just a trivial extra allocation without any functional change for end users.

CHECKOUT-10026.new_google_places_api is currently set to true in integration and staging and false for everyone in production.

Rollout/Rollback

Set CHECKOUT-10026.new_google_places_api experiment to false if the store where we rolled out the feature is affected. For issues with other stores revert the PR.

Testing

New CI tests + manual testing.

If you want to test yourself you can use these API keys in https://console.cloud.google.com/apis/credentials?project=bc-hackathon-env:

1. Google Maps API Key test - our old API key that still has access to old Places API and has no access to new Places API. Represents old users.
2. Maxs Places API Key Test - our new API key that has access to new Places API and no access to old Places API. Represents new users.

My tests are below:

With experiment set to false (same as current production)

Existing customers with old API keys:

Screen.Recording.2026-06-30.at.3.16.03.PM.mov

New customers with new API keys (doesn't work):

Screen.Recording.2026-06-30.at.3.18.15.PM.mov

With experiment set to true

Existing customers with old API keys (Initial 403, then fallback to the old service. Billing step will remember that we fallback and skips new api):

Screen.Recording.2026-06-30.at.3.30.18.PM.mov

New customers with new API keys (just works):

Screen.Recording.2026-06-30.at.3.24.12.PM.mov

---

Note

Medium Risk
Touches core address entry and external Google APIs with session-wide fallback behavior; flag-off limits exposure but enabled stores depend on correct dual-API and script-loader wiring.

Overview
When experiment CHECKOUT-10026.new_google_places_api is on, checkout address line 1 autocomplete routes suggestions and place details through NewGooglePlacesApiService instead of the legacy Maps predictions/getDetails flow. AddressForm reads the flag and passes isNewPlacesApiEnabled into GoogleAutocompleteFormField.

GoogleAutocomplete now chooses new vs legacy per request. On gRPC PERMISSION_DENIED, it sets a module-scoped latch and falls back to legacy for the rest of the session; other errors clear suggestions or skip onSelect without falling back. With the flag off, only legacy runs. When the new path is active, legacy shares getNewGooglePlacesApiScriptLoader() so the Maps script is not loaded twice.

Adds GoogleAutocomplete.test.tsx covering the happy path, permission fallback/latching, transient failures, and flag-off behavior.

^{Reviewed by Cursor Bugbot for commit c05b09f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bc-maxy]

cursor review

[bc-maxy]

cursor review

[bc-maxy]

cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit c05b09f. Configure here.}