Fire Mode: Launch NTP in different modes

[0nko]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1207418217763355/task/1215275434974447?focus=true

Description

This PR implements the functionality that allows launching NTPs specifically in Regular or Browser mode.

Steps to test this PR

• Enable Fire tabs FF in dev settings
• Make Search & Duck.ai option is enabled in AI settings
• Open a new Duck.ai chat tab in Regular mode
• Tap on the + button and tap on "New Fire tab"
• Verify a new tab is launched and the browser is now in Fire Mode (Fire mode theme is used)
• While in Fire Mode, open Duck.ai chat tab
• Tap on the + button and tap on "New tab"
• Verify a new tab is launched and the browser is now in Regular Mode (regular theme is used)

---

Note

Medium Risk
Touches core BrowserActivity lifecycle, mode switching, and intent handling; incorrect deferral or replay could drop tabs or mishandle launch intents, though ProcessIntent consumption is explicitly guarded.

Overview
Adds mode-aware new tab launches from Duck.ai’s “+” menu: New tab switches to Regular mode first; New Fire tab switches to Fire mode first.

Replaces the old FIRE→REGULAR-only deferred Intent stash with a general switchModeThen flow: pending work is stored as PendingModeSwitch (ProcessIntent or OpenNewTab), saved in instance state across activity recreate, then replayed in showWebContent. launchNewTab gains an optional browserMode parameter (default: current mode) and always goes through that deferral path when a switch is needed.

New PendingModeSwitch.kt defines bundle round-tripping; PendingModeSwitchTest covers encode/decode edge cases. runAction documents that carried intents are consumed via processIntent, not re-launched.

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

[0nko]

• Fire Mode: Escape hatch #8917
• Fire Mode: Prepare fire dialog #8902
• Fire Mode: Disable chat sync  #8792
• Fire Mode: Separate Duck chat data #8791
• Fire Mode: Empty state pages #8748
• Fire Mode: Launch NTP in different modes #8742 👈 (View in Graphite)
• Fire Mode: Duck.ai and input widget theme overlay #8725
• Fire Mode: Themes and styles #8714
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

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

[malmstein]

LGTM, approving. did not install or smoke-test the APK — static-only. nice refactor: generalising the old pendingFireToRegularIntent into a typed PendingModeSwitch (ProcessIntent / OpenNewTab) carried across the recreate is clean, and the switchModeThen design that re-enters itself on the recreated instance is genuinely well thought through — the doc comments and the explicit intent-redirection security invariant on runAction are exactly what I'd want to see on this path. the rejection fallback only reaches OpenNewTab(FIRE) when fire is unavailable, which is the right behaviour.

one non-blocking ask before merge: please add the round-trip test for toBundle/toPendingModeSwitch — it's the piece most likely to break quietly and the easiest thing here to cover. and since I didn't run it, worth a quick device check of the chat-menu "new tab" / "new fire tab" entries and an external LAUNCH_REQUIRES_REGULAR_MODE intent arriving while in fire mode, to confirm the deferred action survives the recreate.

[malmstein]

toBundle / toPendingModeSwitch is the load-bearing part here — if it doesn't round-trip cleanly the deferred action is silently lost across the recreate. it's pure and Android-testable (same AndroidJUnit4 setup as RealTabTitleResolverTest from #8714) — can we add a round-trip test covering both PendingAction variants plus the null/garbage-bundle paths (unknown action, bad mode name, missing intent) before this merges?

[0nko]

Added PendingModeSwitchTest (AndroidJUnit4, same setup as RealTabTitleResolverTest) — round-trips both PendingAction variants plus the null paths: empty bundle, unknown mode name, missing action, unknown action, and ProcessIntent with a missing intent. The malformed-bundle cases start from a valid bundle and corrupt one field, so a stale wire-format key fails the test rather than silently passing. 12f228066c.