fix(android): calls outlive the activity, as in other calling apps

[sboily]

The problem

onHostDestroy, added in #724 to "stop all calls and processes when app is killed", ends every call and kills the process (killProcess) whenever the React activity is destroyed. That is not the app being killed. On Android 10 and Android 16 emulators, with the example app and an answered call:

During the call	master	this PR
Font size changed (any configuration change the activity doesn't handle: language, display size...)	call ended, app closed	call goes on
Back (Android 11 and earlier destroy the root activity)	call ended, app closed	call goes on
App swiped away from Recents	call ended, app closed	call goes on
App process crashes	Telecom ends the call	Telecom ends the call (unchanged)
React Native reloads its JavaScript (debug build)	call stays active in Telecom, no JavaScript handles it	call ended

In the first three cases the process and React Native's runtime keep running (React reuses its instance and only mounts the screen again). Telecom keeps the process running during a call, with or without the foreground service: swiping the app away without foregroundService also leaves the process and the call (checked on both versions). Service.onTaskRemoved is never called on the ConnectionService when the app is swiped away, so it's no signal either.

The change

A call lasts as long as something can handle it, as in WhatsApp or Teams:

• The activity is destroyed: nothing happens; the call goes on, and the user gets back to it from the app or its notification.
• The process dies: Telecom ends its calls.
• React Native's instance stops while the process runs (a reload, an over-the-air update): the module's invalidate() ends the calls, on the main thread (React Native may invalidate elsewhere). endCallsWhenReactNativeStops: false keeps them, for apps whose native code owns the calls (feat: show an incoming call from native code, and observe events natively on iOS #906). It replaces endCallsOnHostDestroy from feat(android): foregroundServiceType and endCallsOnHostDestroy options #905, which hasn't been released.

The example keeps its call state and CallKeep's listeners outside the screen, registered once from index.js: before, its calls lived in the component's state, so a recreated activity showed no call even though it went on. setup() still runs from the screen (it can ask for permissions on Android), once per mode, and the events replayed from before it (didLoadWithEvents) wait for it: a call started from Recents on an iOS cold start needs it. docs/setup.md has a Calls and the app's lifecycle (Android) section; the changelog lists it under Changed.

Tests

• tests/android/CallKeepCallLifetimeOptionsTest.kt: theCallOutlivesTheActivity (master: the process is killed, reported as a crash), theCallEndsWhenReactNativeStops (master: the call outlives React Native), nativeCallsOutliveReactNative; with the type test, OK (4 tests). The other eight fixtures, including feat: show an incoming call from native code, and observe events natively on iOS #906's native setup, pass on Android 10.
• The table above: the example app, release builds (debug for the reload, with its own Metro), on Android 10 and 16 emulators. With this PR, after each of the first three events the reopened app shows Alice (example) · active, and hanging up from it leaves no call in dumpsys telecom. The mode switch still runs setup() again.
• The example passes tsc and ESLint. Its JavaScript changed on iOS too (listeners at startup, the replay waiting for setup()): on an iPhone 15 Pro Max with iOS 27, an incoming call works, and calling back from the Phone app's Recents with the app not running opens it and starts the call.