fix: Android In-App Browser Crash

[weitingsun]

The app crashes on Android when users grant camera + microphone permissions through the in-app browser (e.g., visiting https://permission.site/).

Root Cause:
The WebView permission handling code had a fundamental architectural flaw when multiple permissions (camera + microphone) were requested simultaneously:
Old behavior: Showed separate dialogs for each permission (one for camera, one for microphone)
Each dialog's "Allow" button independently called request.grant()
Android's WebView API only allows calling grant() or deny() once per permission request
When the user clicked "Allow" on the second dialog → CRASH: "Either grant() or deny() has been already called"

Solution:
Rewrote the permission handling logic in RNCWebChromeClient.java:
Changed permission handling to show ONE dialog for all permissions:

"Allow example.com to use your camera and microphone?"
Call grant() only once with all permissions together
Added error handling to prevent crashes in edge cases

---

Note

Refactors RNCWebChromeClient to show one combined permission dialog and call grant() once with all resources, adding safe state management and error handling to prevent crashes.

• Android WebView permissions (RNCWebChromeClient):
  • Single combined dialog for already OS-granted permissions (e.g., camera and microphone) with host-aware message; 500ms positive-button delay retained.
  • Single grant() call with all requested WebView resources; map Android permissions back to WebView resources before granting.
  • State management: reset grantedPermissions and permissionRequest; only set permissionRequest when system permissions must be requested; clean up on deny.
  • System permission flow: request missing Android permissions via requestPermissions; handle pending permissions queue as before.
  • Error handling: wrap permissionRequest.grant(...) in try/catch in both dialog path and permissions listener to avoid IllegalStateException when already resolved.

^{Written by Cursor Bugbot for commit 73320c4. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Null Permission Label in Protected Media Dialog

When RESOURCE_PROTECTED_MEDIA_ID permission is requested with mAllowsProtectedMedia=false, the variable requestPermissionIdentifier is never set (remains null). If this permission ends up in the permissionsNeedingDialog path (line 191-192), null is added to permissionLabels. This causes the permission dialog to display "Allow [host] to use your null?" to the user, or "camera and null" if combined with other permissions. The fix should set requestPermissionIdentifier = "protected media" or similar for the RESOURCE_PROTECTED_MEDIA_ID case at line 174-186.