Extract the RN-free half of `ScrollView` interop from `ScrollViewResponderInterceptor` (#4376)

## Description

`useJSResponderHandler` and the v3 press components imported
`JSResponderContext`, `updateResponderEventValue`, and
`isKeyboardDismissingTap` from `ScrollViewResponderInterceptor` — a
module coupled to react-native (`Keyboard`, `TextInput`, `Platform`,
`View`). This PR splits the module along that line.

The react-native-free half of the contract between the GH `ScrollView`
and the pressables/detectors inside it moves to a new
`v3/scrollViewInterop.ts` leaf: the `JSResponderContext` and its value
type, `updateResponderEventValue`, the keyboard-visibility state, and
the `isKeyboardDismissingTap` policy. Its only dependency is `react`.
The interceptor keeps all platform plumbing and feeds keyboard
visibility into the leaf through a new `setKeyboardVisibility()` seam
from its `Keyboard` listeners, so consumers of the policy never touch
the platform API.

`KeyboardShouldPersistTaps` becomes a structural copy of RN's union
(including the deprecated boolean form) so the leaf needs no
react-native type import. No behavior change; no re-export stubs kept —
the module is internal and has no external consumers (checked GitHub
code search for the old path).

## Test plan

- `yarn ts-check` clean; `yarn test` 103/103; `yarn lint:js` 0 errors
- The keyboard suites in `api_v3.test.tsx` cover the seam end-to-end in
jest: they emit `Keyboard` events through the interceptor's listeners
and assert dismissal/persist behavior via the moved logic
- Verified on iOS simulator and Android emulator (expo-example,
`keyboardShouldPersistTaps` test screen, real software keyboard):
`never` mode — keyboard-dismissing tap on GH Pressable is swallowed and
dismisses the keyboard, follow-up tap fires normally; `handled` mode —
press fires and the keyboard stays up (responder marking through the
moved context)