fix: align openPicker TurboModule spec to 3 args (fixes New Architecture crash)

[shahidrogers]

Problem

On the New Architecture, the codegen spec for openPicker declares a single argument:

// src/fabric/NativeRNDatePicker.ts
openPicker(props: UnsafeObject): void

But the picker is actually opened with three arguments on iOS, and the iOS native method is defined with three:

// src/modal.js
ios: [props, onConfirm, onCancel]

// ios/RNDatePickerManager.mm
RCT_EXPORT_METHOD(openPicker:(NSDictionary *) props
                  onConfirm:(RCTResponseSenderBlock) onConfirm
                  onCancel:(RCTResponseSenderBlock) onCancel)

Under bridgeless / TurboModules the argument count is validated against the spec, so calling openPicker throws at runtime (the spec expects 1 arg, JS passes 3). This shows up as hard-to-diagnose crashes when the picker is opened on the New Architecture — related reports: #795, #699, #924.

Fix

Make the spec the source of truth at three arguments and align every platform to it:

• src/fabric/NativeRNDatePicker.ts — spec now declares onConfirm / onCancel, matching the iOS native signature and what JS already passes.
• ios/RNDatePickerManager.h / .mm — RNDatePickerManager conforms to NativeRNDatePickerSpec and provides getTurboModule under RCT_NEW_ARCH_ENABLED (the native openPicker already took the three args, so no logic change).
• android/.../DatePickerModule.java — the openPicker override takes the two Callback params so it matches the regenerated 3-arg spec. Android delivers confirm/cancel through the RCTDeviceEventEmitter, so the callbacks are intentional no-ops (commented inline).
• src/modal.js — pass two no-op callbacks on Android so the call site satisfies the new argument count on both platforms.

The spec can't diverge per-platform, so the shared 3-arg shape (with Android no-ops) keeps codegen happy while preserving each platform's existing result-delivery mechanism.

Verification

• yarn typecheck, yarn test, and eslint on the changed JS/TS files all pass. (Two pre-existing prettier errors in src/DatePickerIOS.js are untouched by this PR.)
• The native changes could not be compiled in my environment, but this exact set of changes is running in production in a React Native 0.83 app on the New Architecture (iOS + Android), where it resolves the openPicker crash. Happy to adjust to fit CI/codegen expectations for the repo's baseline RN version.

[shahidrogers]

Both failing checks are pre-existing / environmental — neither is caused by this PR:

• Check / Lint: two prettier/prettier errors in src/DatePickerIOS.js (lines 26–27). That file is not part of this PR, and the same errors are present on master.
• Build / iOS: fails in the CocoaPods setup step, before any source is compiled:

  gem install cocoapods -v 1.11.3
  ERROR: ffi requires Ruby version >= 3.0, < 4.1.dev. The current ruby version is 2.7.5.203.
  

  setup-cocoapods pins CocoaPods 1.11.3 on Ruby 2.7.5, and ffi has dropped Ruby 2.7 support, so pod install/xcodebuild never run.

The checks that actually exercise this change all pass — notably Build / Android ✅, which compiles the new-arch DatePickerModule.java against the regenerated 3-arg codegen spec, plus Check / Types, Test / Javascript, and Test / Android - Unit. The only thing left unverified is the iOS compile, which is blocked by the Ruby/CocoaPods infra issue rather than by the code.

Happy to open a small separate PR to unblock CI (fix the pre-existing DatePickerIOS.js lint and bump the iOS workflow's Ruby/CocoaPods versions) if that would help.