fix(ios): serialize Fabric Modal presentation and dismissal

[nahooni0511]

Summary:

Reopening a single iOS Fabric Modal while its animated dismissal is still running can leave an empty RCTFabricModalHostViewController presented above the application, blocking all touches even after React renders visible={false}.

The minimal sequence is true at 0ms, false at 600ms, true at 650ms, and false at 1000ms with animationType="fade". The base implementation reproduces this in the simulator. UIKit retains an appeared, full-screen controller with no child views, while its detached Fabric host has _isPresented == NO and _viewController == nil.

This change:

• Serializes presentation and dismissal; visibility changes during a transition are reconciled from the latest request when that transition completes.
• Keeps the presented state until dismissal actually completes.
• Does not send a terminal onDismiss or restore outside accessibility focus if that dismissal is immediately followed by a queued reopening. This is intentional: the JS Modal's onDismiss clears its rendered state, which otherwise belongs to the newer visibility request. The final dismissal still emits onDismiss.
• Captures the controller for each completion. If the host is recycled, an old presentation is cleaned up without mutating the reused host, and old dismissal callbacks cannot affect its new controller.
• Adds nine transition tests alongside the three existing modal dismissal tests.

Related: #50152; single-modal reproducer and native state evidence. This PR targets the single-host transition race, not general stacked-modal support, and does not claim to resolve every multi-modal variant in that issue.

Changelog:

[IOS] [FIXED] - Prevent an invisible Fabric Modal from blocking touches when visibility changes during presentation or dismissal.

Test Plan:

Tested on an iPhone 15 Pro simulator running iOS 27.0, Xcode 27.0 (27A266a), arm64 Release.

Native regression tests: compiled the complete changed component and the test file in a targeted XCTest harness, against available RN 0.86.3/Hermes prebuilt dependencies. The component is renamed at compilation to coexist with the framework's original class; its implementation is included directly from this PR source.

xcodebuild test \
  -project .modal-validation/ModalValidation.xcodeproj \
  -scheme ModalTests -configuration Release \
  -destination "id=$SIMULATOR_ID" \
  -derivedDataPath /tmp/rn-modal-native-tests \
  -parallel-testing-enabled NO CODE_SIGNING_ALLOWED=NO

• Patched component: 12 tests pass, zero failures.
• Same tests with the base component from d2a6ce5: 8 failing tests (13 assertion failures). The three existing nested-controller tests and synchronous transition test pass.
• Cases include hide-during-presentation, reopen-during-dismissal, latest-request coalescing, detaching during presentation, recycling during either transition, and synchronous completion.

Actual UIKit/JS reproduction: compiled both the base and patched component into separate simulator-only libraries. A test-only factory hook substitutes either implementation under Fabric's Modal handle in the same Expo 57.0.20 / RN 0.86.3 Release host, with a minimal React/React Native-only entry. Base blocks the counter button; patched accepts the tap. A second sequence keeps the queued reopening visible until 3000ms: it presents again, dismisses, and restores touch access with the patch.

Checks: repository clang-format check for both changed files and git diff --check pass.

Repro source, complete harness, commands, and screenshots are on a separate evidence branch so they do not expand this PR's source diff. The original reproducer is also included inline in the linked issue comment.

Base: tap is blocked	Patched: counter increments

Validation limits: a full RNTester build and all-platform suites were not run. The harness compiles this PR's native implementation, but links RN 0.86.3 prebuilt dependencies rather than rebuilding every dependency from main. Android/tvOS are not runtime-tested. In particular, the queued-reopening onDismiss behavior and accessibility focus handling warrant maintainer review.

[meta-cla]

Hi @nahooni0511!

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!