Add onNativeTouchEnd event (Android finger-lift from WebView MotionEvent stream)

[artemlitch]

What

Adds a new onNativeTouchEnd direct event to the WebView. It fires from the WebView's own MotionEvent stream on a terminal gesture action, with a typed payload:

onNativeTouchEnd?: (event: { nativeEvent: {
  action: 'up' | 'cancel' | 'pointerUp';
  pointerCount: number;
  x: number;
  y: number;
} }) => void;

Why

On Android, once Chromium's native text-selection controller seizes a selection-drag gesture, it dispatches touchcancel/pointercancel and delivers no further events to React Native's view tree or the WebView's DOM — so RN's View.onTouchEnd, onPointerUp, RNGH onTouchesUp, DOM touchend/pointerup all get cancelled and never report the finger lift.

The WebView's own dispatchTouchEvent, however, still receives the real ACTION_UP on a selection-drag release. This event surfaces that signal so a consumer can reliably detect when the user finishes a text selection. (Used downstream to fix First Class Lookup not opening on Android word-select.)

Verified on a Pixel 6a: a 2–3 word drag-select release reports action: 'up'; a selection-handle re-drag (separate popup window) reports only 'cancel'.

Changes

• Codegen spec + JS types (src/RNCWebViewNativeComponent.ts, src/WebViewTypes.ts) with the typed string-union action.
• Android: new TopNativeTouchEndEvent, a dispatchTouchEvent override (observe-only — always returns super, no behavior change), mapping the MotionEvent action to the string, registered in both old- and new-arch managers.
• iOS: no-op RCTDirectEventBlock property + export so the shared codegen interface stays consistent across platforms (never fired on iOS/macOS).
• Rebuilt lib/ (declarations + view config).

Risk

dispatchTouchEvent is observe-only and always returns super.dispatchTouchEvent(event), so existing touch/scroll/selection behavior is unchanged. The event is Android-only; the iOS side is a compile-time stub.

🤖 Generated with Claude Code