Add custom AI onboarding referrer parser and plumbing to enable the onboarding plan

[LukasPaczos]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1208671518894266/task/1215753390280440?focus=true
Tech Design URL (if applicable):

Description

Stacked on #8852.

• CustomAiOnboardingStore / CustomAiOnboardingStoreImpl — a single component that is both the referrer parser plugin (writes the onboarding=ai flag on first launch) and the reader of the custom AI onboarding decision. The decision is made once and then frozen. resolve() waits for the install referrer to resolve, then returns true only when the referral flag is set and the customDuckAiOnboarding, linearOnboardingOrchestrator and brandDesignUpdate flags are all enabled, and persists that result. isEnabled() is a cheap read of the persisted decision and does not re-evaluate, so the run is chosen once at plan build time and every later reader (onboarding pages, end-of-journey CTAs) sees the same value rather than recomputing and possibly diverging from the chosen plan. The two roles are split across CustomAiOnboardingResolver (decide and write) and CustomAiOnboardingStore (read).
• NewUserOnboardingPlanProvider — picks the custom AI plan from resolve(), arms the in-context Duck.ai demo up front, and gates the input screen preview and Duck.ai demo steps behind the singleTabFireDialog flag as this feature is required for these steps to be executed.

Steps to test this PR

See this for context on how to test referrals.

Also see Figma.

• Uninstall the app
• Apply this patch:

diff --git a/app/build.gradle b/app/build.gradle
index 541dfe1a58..5f5570725f 100644
--- a/app/build.gradle
+++ b/app/build.gradle
@@ -142,7 +142,7 @@ android {
     }
     buildTypes {
         debug {
-            applicationIdSuffix ".debug"
+//            applicationIdSuffix ".debug"
             pseudoLocalesEnabled false
             manifestPlaceholders = [
                     appIcon     : "@mipmap/ic_launcher_blue",
 }

• Change build type to PlayDebug
• Open this link on the test device: https://play.google.com/store/apps/details?id=com.duckduckgo.mobile.android&referrer=utm_campaign%3Dappnosupport-atb-appnosupport%26origin%3Dfunnel_appnosupport_website
• Install the app (remember to use PlayDebug)
• Verify you don't see the + Duck.ai on the intro animation and a regular onboarding flow launches
• Uninstall the app
• Open this link on the test device: https://play.google.com/store/apps/details?id=com.duckduckgo.mobile.android&referrer=utm_campaign%3Dappnosupport-atb-appnosupport%26origin%3Dfunnel_appnosupport_website%26onboarding%3Dai
• Install the app (remember to use PlayDebug)
• Verify you don't see the + Duck.ai on the intro animation and a regular onboarding flow launches.
• Additionally apply this diff:

diff --git a/app/src/main/java/com/duckduckgo/app/onboarding/CustomDuckAiOnboardingFeature.kt b/app/src/main/java/com/duckduckgo/app/onboarding/CustomDuckAiOnboardingFeature.kt
index 8ccb40d67a..d862242281 100644
--- a/app/src/main/java/com/duckduckgo/app/onboarding/CustomDuckAiOnboardingFeature.kt
+++ b/app/src/main/java/com/duckduckgo/app/onboarding/CustomDuckAiOnboardingFeature.kt
@@ -27,6 +27,6 @@ import com.duckduckgo.feature.toggles.api.Toggle.DefaultFeatureValue
 )
 interface CustomDuckAiOnboardingFeature {
 
-    @Toggle.DefaultValue(DefaultFeatureValue.FALSE)
+    @Toggle.DefaultValue(DefaultFeatureValue.TRUE)
     fun self(): Toggle

• Open this same link on the test device again: https://play.google.com/store/apps/details?id=com.duckduckgo.mobile.android&referrer=utm_campaign%3Dappnosupport-atb-appnosupport%26origin%3Dfunnel_appnosupport_website%26onboarding%3Dai
• Install the app (remember to use PlayDebug)
• Verify you see the + Duck.ai on the intro animation and a custom AI onboarding flow launches

---

Note

Medium Risk
Changes first-launch onboarding plan selection and install-referrer timing, with broad wiring in browser CTAs and the linear orchestrator; mitigated by persisted frozen decisions and extensive unit tests.

Overview
Introduces CustomAiOnboardingStore as the single place for the Play Install Referrer onboarding=ai signal, a one-time resolve() decision (referrer + feature toggles), and a frozen isEnabled() read so the whole app agrees on whether the custom AI plan ran. Custom-AI helpers are removed from OnboardingStore (no more stub isCustomAiOnboardingFlow()).

NewUserOnboardingPlanProvider now branches on customAiOnboardingResolver.resolve(), arms the in-context Duck.ai demo at plan build, and gates the input preview / Duck.ai demo steps on singleTabFireDialog. Finish/skip of the custom path arms a one-shot open input on Duck.ai via the new store.

Browser and CTA layers switch to customAiOnboardingStore for chat-tab launch, Privacy Pro featurePage=duckai, deferred fire-button dismissal in the custom flow, and custom copy on brand-design end/subscription bubbles (via an explicit isCustomAiOnboardingFlow flag). BrandDesignUpdatePageViewModel loads that flag asynchronously before orchestrator UI. NewUserBrowserOnboardingViewModel no longer arms the demo locally—arming stays in the plan provider.

Tests move from OnboardingStoreImpl to CustomAiOnboardingStoreImplTest and update mocks across CTA/browser/plan/orchestrator tests.

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

[lmac012]

LGTM, just a few nits.

[lmac012]

Is process() running on a background thread? I suspect we may be initializing lazy preferences instance on main thread here.

If on a background thread / once moved to background thread, better to use edit(commit = true) to surface errors that may occur while writing to shared prefs.

[LukasPaczos]

Good catch 👍 yes, process() runs on the main thread.

It has to stay synchronous, though. Consumers poll the result via PlayStoreAppReferrerStateListener#waitForReferrerCode(), which unblocks once parsing finishes. If we moved only the plugin processing to a worker thread, waitForReferrerCode() could unblock before the write landed, causing a race. Moving off the main thread would mean refactoring the whole PlayStoreAppReferrerStateListener, which I'd rather avoid here. We can look at it as a follow-up though.

Since we're on the main thread, apply is the right choice as it updates the in-memory map synchronously (which is what the later resolve() read needs) and flushes to disk async. The write and the read both happen in the same first-launch session, so the in-memory value is mostly what we actually need. Synchronous disk write would only cover a case where app dies mid-onbaording but before the async write finished (plus the additional failure notification). Covering that narrow edge doesn't seem worth it.

[lmac012]

Suggested change

	preferences.edit { putBoolean(PREFS_KEY_ENABLED, resolution) }
	preferences.edit(commit = true) { putBoolean(PREFS_KEY_ENABLED, resolution) }

[LukasPaczos]

See #8914 (comment).