fix: Prevent mutation of global launcherOptions during initialization

[alexs-mparticle]

Summary

The Rokt Kit was mutating the global window.mParticle.Rokt.launcherOptions object during initialization, causing integration name corruption on subsequent initializations.

This code created a reference to the global object, not a copy. When integrationName was modified, it mutated the original global state.

First initialization: "customName" → "mParticle_wsdkv_2.43.0_kitv_1.5.0_customName"
Second initialization: "mParticle_wsdkv_2.43.0_kitv_1.5.0_customName" → "mParticle_wsdkv_2.43.0_kitv_1.5.0_mParticle_wsdkv_2.43.0_kitv_1.5.0_customName"

Testing Plan

Using a sample app, assign a value to window.mParticle.Rokt.launcherOptions.integrationName. Confirm that the integration name matches mParticle_wsdkv_2.43.0_kitv_1.5.0_customName when the launcher is created.

[Copilot]

Pull Request Overview

This PR ensures the global window.mParticle.Rokt.launcherOptions object isn’t mutated when initializing the launcher by cloning it before modification, and updates tests to verify immutability.

• Clone launcherOptions before assigning integrationName
• Update test suite to use constants and assert original options remain unchanged

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Rokt-Kit.js	Wraps launcherOptions in a shallow clone via mergeObjects
test/src/tests.js	Introduces sdkVersion/kitVersion constants and tests immutability

Comments suppressed due to low confidence (1)

src/Rokt-Kit.js:70

• [nitpick] Consider using ES6 object spread ({ ...window.mParticle.Rokt.launcherOptions }) or Object.assign for cloning to simplify the code and potentially replace the custom mergeObjects utility. Also verify if a deep clone is needed when launcherOptions may contain nested objects to avoid unintended shared references.

        var launcherOptions = mergeObjects(