Fix fatal crash in in-app popup WebView initialization

[franco-zalamena-iterable]

Summary

• Adds explicit catch for AndroidRuntimeException in createWebViewSafely() to handle WebView provider failures (e.g., WebView package being updated or unavailable)
• Adds catch for Error to handle rare native library loading failures (e.g., UnsatisfiedLinkError)
• Gracefully dismisses the in-app dialog and logs the error instead of crashing the app

Test plan

• Test in-app popup display on devices with working WebView
• Verify crash is caught gracefully when WebView is unavailable

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: The app crashes with AndroidRuntimeException (wrapping InvocationTargetException) when creating a WebView in IterableInAppFragmentHTMLNotification.onCreateView(). This happens when the system WebView package is being updated or is unavailable. The crash was reported against SDK 3.6.5 and 3.6.6.

Ideal fix plan:

• In SDK 3.6.5, new IterableWebView(context) was called directly in onCreateView with no try-catch — any WebView initialization failure would crash the app. This was the real bug, and it was already fixed in PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999 (commit 6662d7dc7b) which introduced createWebViewSafely() wrapping the constructor in a try-catch for Resources.NotFoundException and RuntimeException.
• Since AndroidRuntimeException extends RuntimeException, the existing catch (RuntimeException e) block in the current createWebViewSafely() already catches the exact exception in the issue's stack trace. The issue as reported is already resolved on the current main branch.
• No additional code changes are strictly needed to fix the reported crash.

What the PR did:

• Added an explicit catch (AndroidRuntimeException e) block before the existing catch (RuntimeException e) — this gives a more specific log message but does not change behavior since RuntimeException already catches it
• Added a catch (Error e) block to handle hypothetical UnsatisfiedLinkError and similar — defensive but unrelated to the reported issue
• Added a private static final String TAG field to IterableWebView.java that is never used in the diff

Assessment:

• Root cause identified: partially — the PR correctly identifies that AndroidRuntimeException from WebView init needs to be caught, but does not acknowledge that the existing catch (RuntimeException e) already handles it. The real root cause (no try-catch at all in 3.6.5) was already fixed in PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999.
• Fix correctness: correct but redundant — the added catch blocks do not change runtime behavior for the reported crash. The AndroidRuntimeException catch is purely cosmetic (better log message). The Error catch is speculative defense-in-depth.
• Missed: the PR does not recognize that this issue is already resolved on the current codebase. It would be worth closing the issue as fixed (by PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999) rather than adding redundant catch blocks.
• Wrong assessment: the PR implies this crash can still occur on current code, but createWebViewSafely with its RuntimeException catch already prevents it.
• Tests: not strictly needed — the fix is a no-op relative to the existing code. If anything, a test confirming createWebViewSafely returns null (and doesn't crash) when WebView init throws AndroidRuntimeException would validate the existing behavior, but that was the responsibility of PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999.
• Unused code: TAG field added to IterableWebView.java is not referenced anywhere in the diff.