feat(ios): allow inline calendar to fill available width

[Scr3nt]

Summary

PR made with Cursor AI

Motivation

Fixes #1014

This PR resolves layout issues with the iOS DateTimePicker component when using display="inline" (calendar mode):

1. Width Issue: The calendar was not expanding to fill its container width, appearing narrow even when ample space was available

Implementation

Width Fix

Updated the Yoga layout measurement functions to properly respect layout constraints:

• Paper Architecture (RNDateTimePickerShadowView.m): Modified RNDateTimePickerShadowViewMeasure to use full available width in YGMeasureModeAtMost for inline/calendar display
• Fabric Architecture (RNDateTimePickerComponentView.mm): Set larger default width (375pt) for inline style which gets properly constrained by parent
• Intrinsic Content Size (RNDateTimePicker.m): Updated to suggest 375pt width for inline display to help with layout calculations

Key Changes:

• ios/RNDateTimePicker.m: Updated intrinsicContentSize to suggest appropriate dimensions for inline style
• ios/RNDateTimePickerShadowView.m: Enhanced measure function with proper width/height constraint handling
• ios/fabric/RNDateTimePickerComponentView.mm: Updated updateMeasurements for both width and height

Impact Areas

• iOS Paper Architecture (old React Native architecture)
• iOS Fabric Architecture (new React Native architecture)
• Only affects display="inline" mode (calendar view)
• Other display modes (spinner, compact) remain unchanged

Test Plan

Steps to Reproduce

<View style={{ width: 320 }}>

Compatibility

OS	Implemented
iOS	✅
Android	❌

Note: This is an iOS-specific fix. Android does not have these UIKit warnings.

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

[sterlingwes]

This would be great to land, some suggestions:

• include before/after screenshots showing the changes on new arch vs. old arch and ideally some different device sizes
• the 375 number you have is too small for a bunch of iOS devices I believe (search logicalWidth or pointWidth and you'll see a bunch over 400); ideally this is based on some reference to actual device size (UIScreen?)

If you don't have time to test both paths I would suggest dropping the old arch changes to minimize the surface area here, since this branch is considered frozen these days