Mount children of a legacy view right away so its children stay in step with Fabric's

Summary:
`mountChildComponentView:index:` inserted a child only when it was appended (`index == reactSubviews.count`); any other
insertion was queued in `_viewsToBeMounted` until `finalizeUpdates:`, which only runs when the host view itself is updated
(props, state or layout). A transaction that inserts a child before others and leaves the host view unchanged therefore left the
child unmounted until some later update, and every later `index == count` check failed in the meantime, so more children were
queued (the paper view's order drifted from Fabric's).

With an adapter the child is now inserted at its index (clamped to the number of children) straight away, and
`didUpdateReactSubviews` is called as it was for appended children. The queue is only used before the adapter exists.

Changelog:
[IOS] [FIXED] - LegacyViewManagerInterop mounts a child inserted before other children of a legacy view right away

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Author: habovh

packages/react-native/React/Fabric/Mounting/ComponentViews/LegacyViewManagerInterop/RCTLegacyViewManagerInteropComponentView.mm

@@ -173,17 +173,18 @@ - (void)prepareForRecycle
 
 - (void)mountChildComponentView:(UIView<RCTComponentViewProtocol> *)childComponentView index:(NSInteger)index
 {
-  if (_adapter && index == _adapter.paperView.reactSubviews.count) {
-    // This is a new child view that is being added to the end of the children array.
-    // After the children is added, we need to call didUpdateReactSubviews to make sure that it is rendered.
+  if (_adapter) {
+    // The child is inserted right away, wherever it goes, so that the paper view's `reactSubviews` stay in step with the
+    // Fabric children. A mount that waited for `finalizeUpdates:` would be applied late (the host view is not updated
+    // by every transaction that changes its children) and would shift the position of every later child.
+    // After the child is added, we need to call didUpdateReactSubviews to make sure that it is rendered.
     // Without this change, the new child will not be rendered right away because the didUpdateReactSubviews is not
     // called and the `finalizeUpdate` is not invoked.
+    UIView *target = childComponentView;
     if ([childComponentView isKindOfClass:[RCTLegacyViewManagerInteropComponentView class]]) {
-      UIView *target = ((RCTLegacyViewManagerInteropComponentView *)childComponentView).contentView;
-      [_adapter.paperView insertReactSubview:target atIndex:index];
-    } else {
-      [_adapter.paperView insertReactSubview:childComponentView atIndex:index];
+      target = ((RCTLegacyViewManagerInteropComponentView *)childComponentView).contentView;
     }
+    [_adapter.paperView insertReactSubview:target atIndex:MIN(index, (NSInteger)_adapter.paperView.reactSubviews.count)];
     [_adapter.paperView didUpdateReactSubviews];
   } else {
     [_viewsToBeMounted addObject:@{
@@ -195,9 +196,8 @@ - (void)mountChildComponentView:(UIView<RCTComponentViewProtocol> *)childCompone
 
 - (void)unmountChildComponentView:(UIView<RCTComponentViewProtocol> *)childComponentView index:(NSInteger)index
 {
-  // `index` is the child's position among the Fabric children. It is not its position in the paper view's
-  // `reactSubviews` while mounts are queued in `_viewsToBeMounted`, as those are only inserted in `finalizeUpdates`.
-  // The child named by the mutation is therefore looked up instead of trusting `index`.
+  // The child named by the mutation is looked up instead of using `index` as a position in the paper view's
+  // `reactSubviews`: the two differ whenever a mount is still queued in `_viewsToBeMounted`.
 
   // A child whose mount is still queued never reached the paper view: forget the mount.
   for (NSDictionary *mountInstruction in [_viewsToBeMounted copy]) {