Compose Android keyboardType and secureTextEntry into one input type

[YevheniiKotyrlo]

Summary:

Depends on #59013; the first commit here is that PR.

keyboardType and secureTextEntry both write the class and variation of the staged input type, each with bit edits applied in the order the props arrive. A variation is a value within its class rather than a set of flags (0x10 is TYPE_TEXT_VARIATION_URI in the text class and TYPE_NUMBER_VARIATION_PASSWORD in the number class), so the committed input type depends on that order:

• secureTextEntry={false} clears the url and visible-password variations.
• email-address with secureTextEntry commits TYPE_TEXT_VARIATION_WEB_EDIT_TEXT, which TextView does not mask.
• secureTextEntry set after autoCapitalize="words" or "characters" commits text + URI, which TextView does not mask either: checkPasswordType reads the capitalization flags as the number flags they share bits with (🐛 [Android][TextInput] when combine secureTextEntry + autoCapitalize props #28709).
• Changing keyboardType keeps the previous variation and number flags: url then email-address commits TYPE_TEXT_VARIATION_EMAIL_SUBJECT (Changing TextInput keyboardType from visible-password does not unset the underlying flags (Android) #17248), and numeric then number-pad keeps the signed decimal keys.
• phone-pad with secureTextEntry commits a variation the phone class does not define.

Both setters now only stage their value, and onAfterUpdateTransaction resolves the class and variation once, before reconcileAutoCapitalize reads the class, the same deferral autoCapitalize already uses. A secure field takes its class's password variation; a class without one keeps its keyboard, so phone-pad stays unmasked as before.

Changelog:

[ANDROID] [FIXED] - Fix keyboardType and secureTextEntry overwriting each other's input type

Test Plan:

Seven cases in ReactTextInputPropertyTest; the order-dependent ones apply the two setters in both orders within one transaction. With #59013 alone, six fail (first failure of each):

Test	Expected	Was
testSecureTextEntryFalseKeepsTheKeyboardVariationInEitherPropOrder (url, keyboard first)	0x11	0x01
testSecureTextEntryMasksEveryTextKeyboardInEitherPropOrder (email-address)	0x81	0xA1
testSecureTextEntryStaysMaskedWithWordCapitalization	0x81	0x11
testChangingTheKeyboardTypeReplacesItsVariationAndNumberFlags	0x21	0x31
testRevealingAPasswordRestoresTheKeyboardVariation	0x11	0x01
testSecureTextEntryLeavesAKeyboardWithNoPasswordVariationAsItIs	0x03	0x13

testSecureTextEntryUsesTheNumberPasswordForNumberKeyboards passes before and after; giving number keyboards the text password makes it fail alone.

• ./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest -PenableWarningsAsErrors=true -Preact.internal.useHermesStable=true: 681 tests, 0 failures.
• node ./scripts/format-kotlin.js --check passes.
• The same change on 0.86.3, in an app whose inputs pass secureTextEntry={false}: on a Galaxy S23 (Android 14) the focused editor's EditorInfo reads TYPE_CLASS_TEXT with TYPE_TEXT_VARIATION_URI for keyboardType="url" and with TYPE_TEXT_VARIATION_VISIBLE_PASSWORD for keyboardType="visible-password"; without it, visible-password read TYPE_NULL with no variation.
• Not run: the RNTester build and Android lint (build_android).