[Fix] NPE by getScheduleBackgroundRunIn

[jinliu9508]

Description

One Line Summary

Fixes a NullPointerException issue thrown by SessionService.getScheduleBackgroundRunIn.

Details

Motivation

With the optimization introduced to initWithContext, part of the initialization is now performed in the background after initWithContext is called. This change created a rare race condition where services are accessed shortly after startup, but initialization hasn’t completed. In one scenario, when the app goes into the background before SessionService finishes initializing, a lifecycle callback fires to notify the "unfocus" event, attempting to access SessionService, whose component is null at that time. This error can crash the app and disrupt background services. This PR prevents the crash by ensuring that all major components of SessionService are available during the initWithContext phase.

Scope

This PR moves part of SessionService initialization from start() (which was previously running in the background after initWithContext) to bootstrap(), which is called and completed during the initWithContext phase.

Manual testing

I used a manual approach to reproduce the crash and verify the fix is working for the crash.

Step to reproduce:

1. Pull the first commit and run the demo app. During initialization, swipe the app into the background. (Note: This commit includes an arbitrary 10-second delay to the session service start time for testing purposes.)
2. Wait a few seconds and observe the crash in the background.

After the fix:
Following the same reproduction steps, the error no longer appears, and the session service functions as expected.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[jinliu9508]

Squashing all commits into one before merge