Add callback for push notification click events

[franco-zalamena-iterable]

Summary

• Add IterableNotificationClickHandler callback interface for push notification click events
• Include payload data in launch Intent extras (already present via itbl key)
• Allow registration of click handler through IterableConfig.Builder.setNotificationClickHandler()
• Make IterableNotificationData public so it can be used in the callback

Test plan

• Register click callback and verify it fires on notification tap
• Verify payload data is accessible in the callback (notificationData and extras Bundle)
• Verify backward compatibility without callback registered

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: Users need a way to detect push notification click events and access the notification payload. The existing SDK sets payload data internally but provides no callback mechanism, forcing users to rely on workarounds like inspecting onNewIntent Intent extras.

Ideal fix plan:

• Create a public callback interface that delivers notification click events with the parsed notification metadata and raw payload
• Add a configuration option to register this handler through IterableConfig.Builder
• Make IterableNotificationData public so consumers can use the type in their callback implementation
• Invoke the callback in the push action handling path, covering both immediate execution and deferred execution (when the SDK initializes after the click)
• Add unit tests verifying the callback fires with correct data in both immediate and deferred scenarios

What the PR did:

• Created IterableNotificationClickHandler interface with onNotificationClicked(IterableNotificationData, Bundle)
• Added setNotificationClickHandler to IterableConfig.Builder
• Made IterableNotificationData class public
• Invokes the handler inside executeAction() in IterablePushNotificationUtil

Assessment:

• Root cause identified: yes -- the SDK lacked a public notification click callback mechanism
• Fix correctness: correct -- the approach is sound. Placing the callback in executeAction() means it fires for both immediate and deferred (pending action) paths, which is the right spot.
• Missed:
  • No tests were added. At minimum, a unit test should verify the handler is invoked with the correct IterableNotificationData and Bundle when executeAction runs, and that nothing breaks when no handler is registered (null safety path).
  • Thread safety / lifecycle note: The callback fires from executeAction, which can run during processPendingAction triggered from onResume/onNewIntent or from handlePushAction. It would be worth documenting on which thread the callback is invoked so consumers don't accidentally do heavy work on the main thread or miss a threading concern.
  • Minor: the action.intent.getExtras() != null guard is defensive but extras should always be non-null at that point since handlePushAction already bails out if extras is null before creating the PendingAction. Not a bug, just a redundant check.
• Wrong assessment: none -- the approach is appropriate for the problem
• Tests: needed but missing -- this is a public API addition and should have at least basic unit test coverage for the callback invocation