What problem would you like to solve? Please describe:

Users with large notification targets (e.g., 1300+ recipients across multiple contact methods) experience slower-than-expected notification delivery due to the hardcoded GlobalCMThrottle limit of 5 messages per 5 seconds per contact method type.

While GoAlert's conservative defaults are intentional (to support reprioritization, avoid downstream rate limits, and reduce noise), some deployments have use cases where higher throughput is acceptable and the tradeoffs are understood.

Describe the solution you'd like:

Add a CLI flag to configure the global message throttle rate, defaulting to the current behavior (5 per 5 seconds).

Implementation would involve:

• New CLI flag with a terse warning about downstream rate limits and reduced reprioritization benefits
• Wiring the flag value into the message engine module's count and GlobalCMThrottle
• Reviewing the pending message fetch limits—GoAlert currently fetches a subset of pending messages plus recent sent ones; higher throughput may require adjusting these calculations
• Updating the CLI markdown documentation
• Adding a smoketest validating before/after behavior

Describe alternatives you've considered:

• Longer-term refactor of the message module could provide more granular control, but that's a larger effort and this provides immediate relief for affected users.
• Users could modify the source directly, but a supported flag is preferable.

Additional context:

This came up from a user sending notifications to ~1300 people with 3 contact methods each (~6500 outgoing messages). Current behavior works as designed but doesn't serve this use case well.

This should be framed as an "advanced/use at your own risk" setting—most users should stick with defaults.