feat: [SDK-5024] add loginWithProfile (Android only)

[abdulraqeeb33]

Description

One Line Summary

Add loginWithProfile(externalId, profile, jwt?): one Create User call that logs in and attaches email, SMS, tags and aliases. Android only for now.

Details

Motivation

Exposes the Android SDK's composite login(externalId, profile) (OneSignal-Android-SDK#2743) so wrapper apps can log in with a profile in a single request and get a typed result back.

Scope

• New method only. Existing login is unchanged (its void return type cannot change).
• Returns a result mirroring the Android wire shape (success, data, error). Never throws or rejects; bad input resolves INVALID_ARGUMENT, anything unexpected resolves UNKNOWN.
• iOS: the iOS SDK has no equivalent yet. On iOS this resolves immediately with { success: false, error: [{ code: "UNKNOWN", source: "CLIENT", message: "loginWithProfile is only supported on Android" }] } and calls no native iOS API, so it cannot crash or hang.
• Android native dependency bumped to 5.11.0 (unreleased, see the comment below).
• Demo: "LOGIN WITH PROFILE" button and dialog, Android only, with the composite_login_* test IDs from the shared spec (sdk-shared#58).

Public API

OneSignal.loginWithProfile(externalId: string, profile: OneSignalUserProfile, jwtBearerToken?: string | null): Promise<OneSignalResult<LoginData>>

TurboModule spec gains loginWithProfile(externalId, profile, jwt): Promise<Object>. Because the spec is shared, RCTOneSignalEventEmitter.mm implements it too and resolves the Android-only envelope (JS also short-circuits on iOS first). Android bridge passes a Continuation from Java, handles the non-suspending return path, and resolves once.

The promise never rejects, unlike other async APIs here. Callers branch on success.

Testing

Unit testing

475 tests pass (98.6% statements). Covers marshalling, result parsing (including dropped-null iOS dictionaries), validation, and the iOS envelope (fails if the guard is removed).

Manual testing

vp check, vp fmt --check, spotlessJavaCheck, demo tsc pass. :react-native-onesignal:compileDebugJavaWithJavac succeeded against the locally published Android SDK; codegen signatures match. iOS not compiled locally, so the .mm change relies on CI. Not run on a device.

Affected code checklist

• Notifications
• 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
• 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 (Android jobs cannot resolve 5.11.0 until it is released, see comment)
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

[abdulraqeeb33]

Heads-up on the native Android dependency, so the red Android CI doesn't cause alarm:

1. This bumps the OneSignal Android SDK to 5.11.0, which is not published yet. It is the release that will carry login(externalId, profile) (OneSignal-Android-SDK#2743, API dump in #2787). Until it is on Maven Central, Android jobs here fail to resolve it. Expected, and why this is a draft.
2. Local verification compiled against 5.11.0-composite-local, which I published from Android main into my own ~/.m2 (mavenLocal). Neither mavenLocal() nor that version is in this diff. The committed version is 5.11.0 only.
3. Plan: release Android 5.11.0, re-run CI, then mark ready for review.