feat: add batch stream wrapper function

[khushi1033]

Summary

Implements the processBatch hook to support batch-level event forwarding. When called by the mParticle SDK after each batch upload, the kit forwards the full batch object (events, user attributes, identities, consent state, and non-event lifecycle data) to window.Rokt.batch_stream on the Rokt WSDK. Mirrors the existing event queue pattern with two new queues: batchQueue (drains when the kit initialises) and batchStreamQueue (drains when batch_stream becomes available).

Updated @mparticle/web-sdk to pull in the latest type definitions (Batch, SDKEvent, IMParticleUser, KitInterface). To fully conform to KitInterface, the following changes were made:

• init and process parameter types widened to match the interface (Record<string, unknown> / SDKEvent), with internal casts to the kit's typed shapes
• Identity callbacks (onUserIdentified, onLoginComplete, onLogoutComplete, onModifyComplete) updated to accept IMParticleUser with the correct second parameter where required
• Public interface methods (init, process, processBatch, identity callbacks, attribute methods) now return descriptive strings on success and error to comply with KitInterface
• id property added to satisfy the required KitInterface.id field
• processEventQueue renamed to drainQueues to reflect that it now drains both the event and batch pre-init queues

Testing Plan

Added #processBatch tests in test/src/tests.spec.ts covering: happy path forwarding, non-event data passthrough, pre-init queuing and flush, batch_stream unavailable queuing and flush, window.Rokt undefined graceful fallback, and flush ordering. All tests existing from before continue to pass without modification.

[jamesnrokt]

Fairly hard to review given the changes to implement the interface at the same time as the batching updates. May be worth splitting?

[alexs-mparticle]

Why are we removing getAllUserAttributes() but keeping the others?

[rmi22186]

We shouldn't need to extend IMParticleUser at all. if you look at the definition, it extends, User, which has all of these.

Yes it's technically a filtered user, but there's no difference bewteen an IMparticleUser and a FilteredUser from an interface perspective, so let's just use IMparticleUser.

[alexs-mparticle]

Works for me!

[rmi22186]

@khushi1033 - just making sure yous ee this comment, since you pushed a change to fix alex's update, which made this comment, and my reply "outdated", and collapsed the comment.

[khushi1033]

@rmi22186 Yeah sorry was still looking into it - I'm running into an issue though, since getMPID and getUserIdentities live on the User base type, which IMParticleUser extends, Typescript can't see them. Seeing in this comment it's intentionally not re-exported so thinking might have to stick to extending until that's updated?

[rmi22186]

@khushi1033 that's probably fine for now because eventually will be removed from . I'd add a comment saying that it needs to be cleaned up in the future so we don't forget. Something to add to our cool down week I'd say.

[mparticle-automation]

🎉 This PR is included in version 1.24.0 🎉

The release is available on:

• v1.24.0
• GitHub release

Your semantic-release bot 📦🚀