fix(ios): correct Flow prop type from enabled to disabled

[patrickwehbe]

Summary

The iOS picker exposes a prop to turn the control on and off, but the Flow type and the actual component disagree on its name.

In src/datetimepicker.ios.js the component destructures disabled and forwards it to the native view as enabled={disabled !== true}. It never reads a prop called enabled. The TypeScript declarations in src/index.d.ts already match this: IOSNativeProps there has disabled?: boolean ("Is this picker disabled?").

The Flow IOSNativeProps in src/types.js was the only place still declaring enabled?: boolean. That meant Flow consumers got an enabled prop that the component ignores, while the prop the component actually uses (disabled) was missing from the Flow type. It is also why the disabled destructure in datetimepicker.ios.js carries a $FlowFixMe[incompatible-type] suppression.

This PR renames the Flow field to disabled?: boolean so the Flow type matches both the component implementation and the existing TypeScript types. No runtime behavior changes.

Test Plan

What's required for testing (prerequisites)?

None beyond the repo toolchain.

What are the steps to reproduce (after prerequisites)?

This is a type-only change, verifiable by reading the three files:

• src/datetimepicker.ios.js reads disabled and maps it to enabled={disabled !== true}; it never reads enabled.
• src/index.d.ts already declares disabled?: boolean for the iOS props.
• src/types.js now declares disabled?: boolean to match, instead of enabled?: boolean.

flow check reports no new errors from this change (the field name now lines up with how disabled is consumed in the component).

Compatibility

OS	Implemented
iOS	✅
Android

Checklist

• I have tested this on a device and a simulator
• I added the documentation in README.md
• I updated the typed files (TS and Flow)
• I added a sample use of the API in the example project (example/App.js)
• I have added automated tests, either in JS or e2e tests, as applicable