Remove hardcoded static for MQTTClientGJ

[AbhijeetMallick]

What changed

• Removed MACH_O_TYPE = staticlib; from all 5 build configurations (Debug/Production/Alpha/Integration/Release) of the MQTTClientGJ target in Courier.xcodeproj
• Rebuilt MQTTClientGJ.xcframework with dynamic Mach-O binaries (device arm64 and simulator arm64/x86_64)
• Bumped MQTTClientGJ.podspec to 1.0.19 (matching the lockstep version bump across all other pods)
• Removed c.static_framework = true flag from CourierMQTT, CourierMQTTChuck, and CourierProtobuf podspecs (from prior commit)

Why

The prior "Distribute pods as dynamic" commit removed the static framework flag from the Swift pods, but MQTTClientGJ remained a static vendored binary. This caused trunk validation to reject CourierMQTT 1.0.19 as dynamic with a transitive static dependency, violating CocoaPods' linking rules.

By making the underlying MQTTClientGJ xcframework dynamic, consumers can now choose their own linkage: dynamic consumers use default use_frameworks!, static consumers add use_frameworks! :linkage => :static in their own Podfile.

[sanju-naik]

By making the underlying MQTTClientGJ xcframework dynamic, consumers can now choose their own linkage: dynamic consumers use default use_frameworks!, static consumers add use_frameworks! :linkage => :static in their own Podfile.

This Consumers can choose the way they want to link works only for Source code pods, doesn't work for pre-built xcframeworks, since these are already built so clients can't choose how to to link them, they get linked based on how they are generated.

So With this change, when we bump MQTTClientGJ on Consumer iOS it gets added as dynamic framework and impacts launch time. @AbhijeetMallick