fix(android): guard null watcher before removeTextChangedListener (#1516)

## Description

`FocusedInputObserver.focusListener` defers removing the `TextWatcher`
via `input.post {}`, added in a previous fix to avoid a crash with
Stripe's input component (see
https://github.com/kirillzyusko/react-native-keyboard-controller/pull/815
in stripe-android, linked in the existing comment). The runnable
captures `watcher` at schedule time, but if it runs after the focused
input has moved on and `textWatcher` is already `null`,
`removeTextChangedListener` is called with a null parameter.

`ReactEditText.removeTextChangedListener` declares its parameter as
non-null (Kotlin `@NonNull` assertion baked into the generated
bytecode), so this throws instead of being a harmless no-op:

```
NullPointerException: Parameter specified as non-null is null: method com.facebook.react.views.textinput.ReactEditText.removeTextChangedListener, parameter watcher
```

We saw this crash in production on Android, on a screen with a PIN-entry
input (rapid focus changes between adjacent input boxes), via Sentry.
Stack trace bottoms out in `FocusedInputObserver`'s deferred runnable.

## Fix

Null-check before calling `removeTextChangedListener`, so the deferred
removal degrades to a no-op when there's nothing to remove, instead of
crashing:

```kotlin
input.post {
  watcher?.let { input.removeTextChangedListener(it) }
}
```

## 🤔 How Has This Been Tested?

- Verified against our production crash reports (Sentry) — the NPE stack
trace matches this exact call site.
- This is a minimal, defensive null-check; it preserves the existing
async-removal behavior (and the Stripe-input workaround it was added
for) and only changes behavior in the case that was previously crashing.

We're carrying this as a local patch via `patch-package` in the
meantime; happy to adjust the fix if you'd prefer a different approach
(e.g. checking at schedule time instead of at execution time).