feat: report mParticle API usage through the Rokt kit

[thomson-t]

Background

Rokt diagnostics can identify native SDK API usage, but calls made through mParticle are not currently distinguishable. This adds bounded, non-sensitive API identifiers only when the Rokt kit is active.

What Has Changed

• Instrument public mParticle core, identity, user, notification, session, and Rokt wrapper APIs
• Forward diagnostics through the active Rokt kit using a fixed uppercase code vocabulary
• Require Rokt SDK 5.3.2 and call its public diagnostics API directly
• Exclude API arguments and values from diagnostic payloads
• Avoid duplicate diagnostics from convenience overloads
• Add core and kit tests for active-kit gating and diagnostic forwarding

Screenshots/Video

N/A — no visual changes.

Testing

• trunk check --ci
• 940 Objective-C unit tests
• 68 Rokt kit tests against Rokt SDK 5.3.2
• pod lib lint for the Rokt kit against the Rokt SDK 5.3.2 podspec
• Coverage validation; MPRokt.m is at 93.5%

Checklist

• Self-review completed
• Tests added or updated
• Tested locally

[cursor]

PR Summary

Medium Risk
Touches many hot-path public API entry points in core; behavior is gated and payload-free, but every integrated app pays a small active-kit lookup cost on those calls.

Overview
Adds non-sensitive, fixed-code diagnostics so Rokt can see which mParticle public APIs were invoked when traffic goes through the SDK rather than the native Rokt SDK.

Core emits uppercase codes (e.g. LOG_EVENT, IDENTIFY, LOGIN) at entry points across mParticle, identity, user, session, notifications, and Rokt wrapper APIs via logRoktApiDiagnostic, which no-ops unless the Rokt kit is active and forwards to the kit’s logMParticleApiDiagnostic:.

Rokt kit maps that to Rokt logMParticleApiCall:additionalInfo: with an empty additionalInfo dict. Rokt-Widget is bumped to 5.3.2 (SPM, podspec, Xcode project); local SPM names the core package explicitly.

logCommerceEvent is refactored so commerce logging does not double-count diagnostics from convenience overloads. Changelog and unit tests cover kit forwarding and active-kit gating.

^{Reviewed by Cursor Bugbot for commit 2d60e1d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

📦 SDK Size Impact Report

Measures how much the SDK adds to an app's size (with-SDK minus without-SDK).

Metric	Target Branch	This PR	Change
App Bundle Impact	1.79 MB	1.79 MB	+N/A
Executable Impact	848 bytes	848 bytes	+N/A
XCFramework Size	6.49 MB	6.49 MB	+4 KB

➡️ SDK size impact change is minimal.

Raw measurements

Target branch (main):

{"baseline_app_size_kb":84,"baseline_executable_size_bytes":75464,"with_sdk_app_size_kb":1920,"with_sdk_executable_size_bytes":76312,"sdk_impact_kb":1836,"sdk_executable_impact_bytes":848,"xcframework_size_kb":6644}

This PR:

{"baseline_app_size_kb":84,"baseline_executable_size_bytes":75464,"with_sdk_app_size_kb":1920,"with_sdk_executable_size_bytes":76312,"sdk_impact_kb":1836,"sdk_executable_impact_bytes":848,"xcframework_size_kb":6648}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6a94529. Configure here.}

[jamesnrokt]

Looks good to me. One thing to confirm is with the logic around kitInstance will we get logs if the kit isn't initialized fully?

[thomson-t]

Looks good to me. One thing to confirm is with the logic around kitInstance will we get logs if the kit isn't initialized fully?

Good question. Before the Rokt Kit is created and active, activeKitsRegistry does not return it, so the diagnostic is a no-op and is not queued by mParticle.
Once the kit is active, the call is forwarded to Rokt.logMParticleApiCall and pre-init queue handles any remaining Rokt SDK initialization timing.