add: security hardening around webview javaScriptEnabled

[jinliu9508]

Description

One Line Summary

Hardened WebView configuration in WebViewManager to prevent potential insecure file access.

Details

Motivation

This change addresses a security scanning finding that flagged unsafe WebView configurations. The goal is to mitigate potential vulnerabilities by limiting JavaScript interfaces and disabling file and universal access.

Scope

• Added a secureSetup(webView) method to centralize and enforce safe WebView defaults.
• Affects only In-App Messaging (IAM) where WebViews are used to display in-app content.
• No behavioral changes for SDK consumers; all updates are internal security hardening.

Testing

Unit testing

N/A – configuration-only changes

Manual testing

RECOMMEND - OPTIONAL - Explain what scenarios were tested and the environment.
Example: Tested opening a notification while the app was foregrounded, app build with Android Studio 2020.3 with a fresh install of the OneSignal example app on a Pixel 6 with Android 12.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[jkasten2]

I see SetJavaScriptEnabled was moved to a new function, but don't we still need to keep AddJavascriptInterface here?

[jkasten2]

I recommend adding a comment here of why this is needed and how our OSJavaScriptInterface follows the standards of checking the input values provided by JS. We can then point to this when future questions come up.