[SDK-361] Preventing push notification from killing exisitng activity

[franco-zalamena-iterable]

🔹 Jira Ticket(s) if any

• SDK-361

✏️ Description

Problem

Tapping an Iterable push while the app is already running destroys the entire existing activity task, forcing a full cold start. In React Native apps this is highly visible - the JS bridge re-initializes and startup logic re-runs. In native apps the same destruction happens silently.

Two compounding issues in IterableTrampolineActivity:

1. No taskAffinity - defaults to the app's package name, so it shares the app's task
2. FLAG_ACTIVITY_CLEAR_TASK on the notification PendingIntent - with a shared affinity, this wipes the app's entire activity stack before the trampoline launches

IterableTrampolineActivity was introduced in MOB-3754 / SDK 3.4.1 for Android 12 trampoline restrictions. The taskAffinity isolation was never added, and FLAG_ACTIVITY_CLEAR_TASK was carried over from the pre-Android-12 path where it was applied to a different intent.

Fix

• Add android:taskAffinity="" to IterableTrampolineActivity - isolates it into its own task, standard practice for transparent routing activities
• Remove FLAG_ACTIVITY_CLEAR_TASK from the trampoline PendingIntent in IterableNotificationHelper and IterableNotificationBuilder - not necessary

References

• SO: Keep Activity state when starting from Notification Intent
• SO: Android Firebase Push notification restarts app when clicked

[Ayyanchira]

This PR is giving good confidence.
It is noticed that Backstack fresh start approach of previous way due to clear task will not be performed. But, instead the apps will now return to its previous activity after the deeplinking activities are done.
Apps can always control the stacking at their level too.

[Ayyanchira]

This change looks promising. Will have to monitor after release for customer feedback if any.