fix(ios): make the unmountChildComponentView assert message bounds-safe

[dongdongbh]

Summary

-[RCTViewComponentView unmountChildComponentView:index:] bounds-checks the RCTAssert condition, but the failure message it formats afterwards calls -objectAtIndex: on the same out-of-range index:

RCTAssert(
    (self.currentContainerView.subviews.count > index) &&              // guarded
        [self.currentContainerView.subviews objectAtIndex:index] == childComponentView,
    @"... tag at index: %@)", ...,
    @([[self.currentContainerView.subviews objectAtIndex:index] tag]));  // not guarded

So the exact situation the assert exists to report — a shadow-tree/native child-index mismatch — raises NSRangeException while being reported, instead of being reported.

That is normally invisible, because a source Release build strips RCTAssert and the mismatch is harmless: index is used only inside the asserts, and the real work, [childComponentView removeFromSuperview], never needed it. But the prebuilt React.framework published to Maven Central is built with assertions enabled (#57454), so this is live in App Store builds — we hit it on RN 0.81.5 via Expo SDK 54, symbolicated against the published reactnative-core-dSYM-release artifact:

NSRangeException: *** -[__NSArrayM objectAtIndex:]: index 13 beyond bounds [0 .. 8]
  -[RCTViewComponentView unmountChildComponentView:index:]  (RCTViewComponentView.mm:163)
  RCTPerformMountInstructions(...)                          (RCTMountingManager.mm:97)
  -[RCTMountingManager performTransaction:]                 (RCTMountingManager.mm:258)
  -[RCTMountingManager initiateTransaction:]                (RCTMountingManager.mm:247)

This is the second of the two fixes suggested in #57454 and stands on its own for any build with assertions enabled.

The change also reads self.currentContainerView once instead of four times. That getter is not a plain accessor — it creates or tears down _containerView and reparents subviews — so re-invoking it inside an assert's arguments is worth avoiding regardless.

Changelog:

[IOS] [FIXED] - Report a RCTViewComponentView child-index mismatch instead of raising NSRangeException while formatting the assert message

Test Plan

I don't have a macOS build environment, so I have not compiled this — flagging that plainly. What backs the change:

• Five App Store crash reports (RN 0.81.5, iOS 26.5.2 / 26.6, three device models) all symbolicate to the message argument on this line, never to the guarded condition.
• strings on react-native-artifacts-0.81.5-reactnative-core-release.tar.gz shows both Attempt to unmount… format strings present, confirming the call sites are compiled into the release artifact — same check [iOS] Prebuilt React-Core Release artifacts are built with NSAssertions enabled — RCTAssert failures become fatal NSRangeException crashes in production #57454 reports for 0.85.3 and 0.86.0, so the artifact defect reaches at least as far back as 0.81.
• Behaviour is unchanged whenever the assert passes; when it fails, the message now prints out of bounds in place of a tag that cannot be read.

Happy to rework this if you would rather the assert drop the tag at index field entirely, or if fixing the artifact build flags is considered sufficient on its own.

[meta-cla]

Hi @dongdongbh!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!