fix: Add Defensive Code when Building URL Signatures

[BrandonStalnaker]

Background

• We received a customer crash report on com.mparticle.messageQueue with the stack pointing into -[MPURLRequestBuilder build] during config request handling.
• The crash occurred while constructing signature strings via NSString stringWithFormat.

What Has Changed

• Added a query length guard in MPURLRequestBuilder for config/audience signature building.
• If query input is too large, request build now logs and returns nil instead of continuing.
• Reworked the affected signature string construction to use safer append-based building.
• Added a unit test to verify oversized config query input returns nil.

Checklist

• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective or that my feature works.
• I have tested this locally.

Additional Notes

• Because this is a malloc-family crash, we cannot prove this line is the original corruption source; it may be a heap-corruption trigger point where a pre-existing memory issue surfaces. This change hardens the observed crash path to reduce risk.

Reference Issue (For employees only. Ignore if you are an outside contributor)

• Closes https://go/j/[SDKE-1102]

[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.82 MB	1.82 MB	+N/A
Executable Impact	896 bytes	896 bytes	+N/A
XCFramework Size	9.49 MB	9.49 MB	+N/A

➡️ 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":1944,"with_sdk_executable_size_bytes":76360,"sdk_impact_kb":1860,"sdk_executable_impact_bytes":896,"xcframework_size_kb":9716}

This PR:

{"baseline_app_size_kb":84,"baseline_executable_size_bytes":75464,"with_sdk_app_size_kb":1944,"with_sdk_executable_size_bytes":76360,"sdk_impact_kb":1860,"sdk_executable_impact_bytes":896,"xcframework_size_kb":9716}

[denischilik]

Discussed in person, looks like we can make secret and api key atomic to remove thread race issue. It will also be good to pass apiKey and secret to builder constructor, to remove additional dependency from MParticle.shared instance

[BrandonStalnaker]

The issues Denis identified were from an older version of the SDK from before James' changes here. The client hasn't confirmed the sdk version being used in relation to this stack trace so its possible that change fixed it. That's part of why this commit is entirely defensive and perhaps overly cautious.