fix: use WindowInsetsCompat to exclude keyboard insets on Android API 23-29

[tp26610]

Summary

On Android API 23–29 (Android 6–10), getRootWindowInsetsCompatM uses the deprecated min(systemWindowInsetBottom, stableInsetBottom) to exclude keyboard height from the bottom inset. On some Android 10 devices (confirmed on Samsung One UI and Nokia with stock Android 10), stableInsetBottom incorrectly reports the keyboard height, causing SafeAreaView to add paddingBottom equal to the keyboard height. This pushes the entire screen content upward whenever a TextInput is focused — even when windowSoftInputMode is set to adjustNothing.

Android 11+ (getRootWindowInsetsCompatR) is unaffected because WindowInsets.Type.navigationBars() explicitly excludes IME insets by design.

Fix: only the bottom inset calculation is changed. top, right, and left continue to use the existing systemWindowInset* values unchanged. The bottom inset is now obtained via ViewCompat.getRootWindowInsets() + WindowInsetsCompat.Type.navigationBars(), which correctly excludes keyboard insets on API 23–29 via the AndroidX compat layer. The original min() approach is kept as a fallback.

androidx.core:core-ktx is also added as an explicit dependency (it was previously only available transitively via react-native).

Test Plan

Tested on:

• Samsung Galaxy (One UI, Android 10) — bottom buttons no longer pushed up when keyboard opens ✅
• Nokia 7 Plus (stock Android 10) — same ✅
• Android 11+ — no regression ✅

To reproduce the original bug: open any screen with a TextInput and a fixed bottom button inside a SafeAreaView on an Android 10 device, focus the input, and observe the button jumping upward.