Keep subview-clipping bookkeeping in sync when addViewAt reparents a view

Summary:
When the Fabric mounting layer inserts a view that unexpectedly still has a parent, `SurfaceMountingManager.addViewAt` takes evasive action and removes the view from its current parent before re-adding it to the new one. That recovery used a raw `ViewGroup.removeView`, which detaches the view from the Android view hierarchy but does not update a clipping-enabled parent's internal child bookkeeping (the `allChildren` array maintained while `removeClippedSubviews` is set).

As a result, the old parent kept a stale reference to a view that had just been reparented elsewhere. A later clipping pass on that parent then asserted the child was still parented to it and threw an `IllegalStateException`, crashing the app.

Route the evasive removal through the current parent's `ViewManager` (when its view state is known) so the clipping-aware removal path runs and the `allChildren` bookkeeping stays consistent. Behavior is unchanged for non-clipping parents, which still fall back to the raw `removeView`.

Changelog:
[Android][Fixed] - Fix rare crash in views using `removeClippedSubviews` when a child is reparented during mounting

Differential Revision: D110059699

Author: rozele

packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/SurfaceMountingManager.kt

@@ -360,7 +360,7 @@ internal constructor(
       // thus prevent the RemoveDeleteTree worker from deleting this
       // View in the future.
       if (currParentView is ViewGroup) {
-        currParentView.removeView(view)
+        removeViewFromCurrentParent(currParentView, view)
       }
       erroneouslyReaddedReactTags.add(tag)
     }
@@ -395,6 +395,33 @@ internal constructor(
     }
   }
 
+  /**
+   * Removes [view] from [currentParent] as part of [addViewAt]'s evasive recovery, keeping any
+   * subview-clipping bookkeeping in sync.
+   *
+   * A raw [ViewGroup.removeView] only detaches the view from the Android hierarchy. When
+   * [currentParent] manages subview clipping (`removeClippedSubviews`), it also keeps an internal
+   * `allChildren` array that is only updated through its [ViewManager]'s removal path; a raw
+   * removal leaves a stale entry there pointing at a view that has just been reparented elsewhere,
+   * and a later clipping pass then trips the parent's `parent === this` invariant and crashes.
+   * Routing the removal through the parent's [ViewManager] (when its [ViewState] is known) reuses
+   * the clipping-aware removal and keeps the bookkeeping consistent; otherwise we fall back to the
+   * raw removal.
+   */
+  private fun removeViewFromCurrentParent(currentParent: ViewGroup, view: View) {
+    val currentParentState = getNullableViewState(currentParent.id)
+    if (currentParentState?.viewManager is IViewGroupManager<*>) {
+      val manager = getViewGroupManager(currentParentState)
+      for (i in 0 until manager.getChildCount(currentParent)) {
+        if (manager.getChildAt(currentParent, i) === view) {
+          manager.removeViewAt(currentParent, i)
+          return
+        }
+      }
+    }
+    currentParent.removeView(view)
+  }
+
   @UiThread
   public fun removeViewAt(tag: Int, parentTag: Int, index: Int): Unit {
     UiThreadUtil.assertOnUiThread()