fix(iOS): forward-declare RCTSurfaceTouchHandler in UIView+RNSUtility.h (#3986)

## Summary

`ios/utils/UIView+RNSUtility.h` declares methods returning
`RCTSurfaceTouchHandler *` and currently `#import`s
`<React/RCTSurfaceTouchHandler.h>` directly in the public header. That
header is shipped in the `React-RCTFabric` clang module, not `React` —
so under `use_frameworks!:linkage => :static` + new arch, any consumer
module that imports the `RNScreens` clang module (e.g. ExpoRouter) fails
Clang's module dependency scanning before compilation:

```
error: Clang dependency scanning failure: While building module 'RNScreens'
  UIView+RNSUtility.h: 'React/RCTSurfaceTouchHandler.h' file not found
error: Compilation search paths unable to resolve module dependency: 'RNScreens'
(in target 'ExpoRouter' from project 'Pods')
```

This PR moves the import out of the public surface:

- `UIView+RNSUtility.h`: replace `#import
<React/RCTSurfaceTouchHandler.h>` with `@class RCTSurfaceTouchHandler;`
forward declaration. Replace `<Foundation/Foundation.h>` with
`<UIKit/UIKit.h>` (since the fabric header was previously providing
UIKit transitively, and this is a `UIView` category — matching the
sibling `UINavigationBar+RNSUtility.h`).
- `UIView+RNSUtility.mm`: add the real `#import
<React/RCTSurfaceTouchHandler.h>`.

This matches the pattern already used by `RNSScreenStack.mm`, where
fabric-internal imports stay inside the implementation file.

Fixes #3985.

## Compatibility

All current internal consumers of `UIView+RNSUtility.h`
(`RNSScreenStack.mm`, `RNSScreen.mm`, and `UIView+RNSUtility.mm` itself)
already `#import <React/RCTSurfaceTouchHandler.h>` directly, so they
retain access to the type without relying on transitive imports from the
public header. No call sites need updating.

The change is purely a compile-time refactor — no symbols, return types,
ABI, or runtime behavior change.

## Test plan

- [x] Verified on the consumer side: under `use_frameworks!:static` +
new arch + RN 0.85.3, the patched header allows ExpoRouter to compile
against RNScreens. Without the fix, `expo run:ios` fails on the Clang
module dependency scanning error above.
- [ ] Maintainers: existing CI matrix should cover both
`use_frameworks!` and non-frameworks builds across new/legacy arch.

## Related

- See #3985 for the full failure trace and reproduction steps.
- Conceptually adjacent to #2306 / #2319 (`RectUtil.h` import path),
which fixed a similar consumer-side compilation failure by relocating a
header import.
- Same family as expo/expo#39080 (consumer → RNScreens internal
headers), but in the opposite direction (RNScreens → React fabric).

Author: zhe-qi

ios/utils/UIView+RNSUtility.h

@@ -1,7 +1,8 @@
 #pragma once
 
-#import <Foundation/Foundation.h>
-#import <React/RCTSurfaceTouchHandler.h>
+#import <UIKit/UIKit.h>
+
+@class RCTSurfaceTouchHandler;
 
 NS_ASSUME_NONNULL_BEGIN
 

ios/utils/UIView+RNSUtility.mm

@@ -1,5 +1,6 @@
 #import "UIView+RNSUtility.h"
 
+#import <React/RCTSurfaceTouchHandler.h>
 #import <React/RCTSurfaceView.h>
 #import "RNSModalScreen.h"