Fire Mode: WebView profile management

[0nko]

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

Description

Isolates WebView state between Regular and Fire browser modes via AndroidX webkit's MULTI_PROFILE API. Each newly-created WebView is bound to its mode-specific androidx.webkit.Profile so cookies, LocalStorage, IndexedDB, and other origin-keyed storage are partitioned per mode. No-op on devices without MultiProfile support.

BrowserTabFragment injects WebViewProfileBinder and calls bind(it, browserMode) inside configureWebView() immediately after inflating the DuckDuckGoWebView, before any settings are applied.

API proposal: WebViewProfileBinder interface

Steps to test this PR

• Smoke test the app and make sure data-clearing works as before. There should be no change to any user-visible functionality

---

Note

Medium Risk
Changes when and how WebViews are profile-bound and how Fire availability is computed; mistakes in bind ordering or profile selection could affect cookie/storage isolation or Fire behavior.

Overview
This PR wires Fire vs Regular browser modes to separate AndroidX WebView profiles when MULTI_PROFILE is supported, so cookies and origin storage (LocalStorage, IndexedDB, etc.) can stay partitioned per mode.

A new WebViewModeInitializer is called from BrowserTabFragment right after the tab WebView is inflated and before any other WebView setup, binding the view to the profile for the current BrowserMode (REGULAR uses the default profile; FIRE uses a dedicated "Fire" profile). RealWebViewModeInitializer no-ops when Fire/multi-profile is unavailable.

WebStorageProvider resolves per-mode WebStorage via ProfileStore when multi-profile is on, otherwise the shared default instance. BrowserMode.profileName centralizes the profile name mapping.

FireModeAvailability is now synchronous (no longer suspend), caches availability at process start and on first read, and checks WebViewFeature.MULTI_PROFILE plus the Fire tabs flag instead of WebViewCapabilityChecker. Tests were adjusted for the new caching and sync API.

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

[0nko]

• Fire Mode: Toggle switch #8606
• Fire Mode: Tab data isolation #8591
• Fire Mode: WebView profile management #8575 👈 (View in Graphite)
• Fire Mode: Rename fire-mode module to browser-mode #8574
• Fire Mode: Add BrowserMode with plumbing #8478
• develop

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

[0nko]

The availability is cached because if the flag changed mid-run, different profiles might be used, which could result in unexpected behavior.

[cursor]

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

^{❌ 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 b1c4058. Configure here.}

[CDRussell]

Smoke tested and it looked ok to me. Reluctant to approve the PR if the public API changes are not covered in a proposal, though. which I didn't think they were (maybe I misremember); are they covered? Because if not, probably will result in changes to these again before merging.

[CDRussell]

are these public API changes covered in a proposal already, for WebViewProfileBinder and WebViewProfileBinder ?

FireModeAvailability had one, though now modified from it to remove suspend.

[0nko]

Added the link for WebViewProfileBinder to the PR description.