iOS: reload input views when keyboardType/returnKeyType change on a focused TextInput (Fabric) (#57868)

Summary:
On the new architecture, changing `keyboardType` (or `returnKeyType`) on a currently focused `TextInput` has no visible effect: the trait is set on the backing view, but the keyboard does not update until the field loses and regains focus.

The legacy architecture handles this correctly — `RCTBaseTextInputView.mm`'s `setKeyboardType:` calls `reloadInputViews` when the field is first responder, with a comment explaining why:

```objc
// Without the call to reloadInputViews, the keyboard will not change until the textview field (the first responder)
// loses and regains focus.
```

That call was not carried over to Fabric's `RCTTextInputComponentView.mm`, where `updateProps:` only assigns `_backedTextInputView.keyboardType`. This PR restores parity by calling `reloadInputViews` when the field is first responder, for both `keyboardType` and `returnKeyType`.

With this fix, apps that switch a focused input between keyboard types (e.g. a chat-style composer that toggles between text and numeric entry) get the same in-place, single-frame keyboard layout swap as the legacy architecture and native UIKit trait updates — instead of having to work around it by remounting the input or swapping focus between duplicate inputs, both of which tear the keyboard down and re-present it.

## Changelog:

[IOS] [FIXED] - TextInput: update the keyboard when `keyboardType`/`returnKeyType` change while the input is focused (new architecture parity with the legacy architecture)

Pull Request resolved: #57868

Test Plan:
In a new-architecture app (RN 0.80, iOS 26 simulator), render a focused `<TextInput>` whose `keyboardType` prop toggles between `default` and `numbers-and-punctuation`:

- Before: the keyboard does not change until focus is lost and regained (or, if the input is remounted as a workaround, the keyboard fully dismisses and re-presents).
- After: the keyboard layout swaps in place in a single frame while the field stays focused, verified by frame-by-frame inspection of a simulator screen recording; behavior matches the same transition performed in Safari (which updates input traits on a single responder) and matches the legacy architecture.

`returnKeyType` changes on a focused field likewise update the return key immediately.

Reviewed By: sbuggay

Differential Revision: D115352138

Pulled By: fabriziocucci

fbshipit-source-id: 1e92edf3e6f592e8a2b10fa5fb8903254cbc280a

Author: NoahDorfman00

packages/react-native/React/Fabric/Mounting/ComponentViews/TextInput/RCTTextInputComponentView.mm

@@ -258,10 +258,18 @@ - (void)updateProps:(const Props::Shared &)props oldProps:(const Props::Shared &
 
   if (newTextInputProps.traits.keyboardType != oldTextInputProps.traits.keyboardType) {
     _backedTextInputView.keyboardType = RCTUIKeyboardTypeFromKeyboardType(newTextInputProps.traits.keyboardType);
+    // Without the call to reloadInputViews, the keyboard will not change until the textInput field (the first
+    // responder) loses and regains focus.
+    if (_backedTextInputView.isFirstResponder) {
+      [_backedTextInputView reloadInputViews];
+    }
   }
 
   if (newTextInputProps.traits.returnKeyType != oldTextInputProps.traits.returnKeyType) {
     _backedTextInputView.returnKeyType = RCTUIReturnKeyTypeFromReturnKeyType(newTextInputProps.traits.returnKeyType);
+    if (_backedTextInputView.isFirstResponder) {
+      [_backedTextInputView reloadInputViews];
+    }
   }
 
   if (newTextInputProps.traits.textContentType != oldTextInputProps.traits.textContentType) {