Add rate limiting for MQTT connection attempts

### Feature Summary

Add rate limiting for MQTT connection attempts at the broker level, before TLS handshake and packet parsing.

### Problem This Solves

Rejected MQTT connections still go through the full TLS handshake, packet parsing, error handling, and logging before being dropped. During customer event, (April 9), bots hit the cluster with ~30k connection attempts per second. Even though authorizeClient rejected every one, the per-rejection cost was enough to take down a 3-node cluster and required scaling to 6x96GB, removing nginx, and 5+ hours of channel WAF onboarding to stabilize.

### Proposed Solution

Rate limit incoming MQTT connections per IP at the broker level, before TLS negotiation. Could be a configurable threshold that drops excess connections immediately with minimal resource cost.

### User Stories

As a platform operator, I want the MQTT broker to drop excessive connection attempts from the same source before TLS handshake so that bot traffic cannot exhaust cluster resources and take down the service.

### Alternatives Considered

During the incident, the team tried: scaling infrastructure, removing nginx to bypass the 65k connection limit, allowing all connections (which just filled up connection slots with bots), and relying on channel WAF. None of these address the root cause at the broker level.

### Priority/Impact

High - critical for user success

### Examples or References

_No response_

### Additional Context

Originally identified during v5 testing of acl-connect. The IB incident confirmed this is a real production risk.

### Are you planning to fix this issue?

Maybe, depending on complexity

### First-time contributor support

- [ ] I'm new to contributing and would appreciate guidance on the process
- [ ] I'd like help understanding the project structure
- [ ] I need assistance with setting up the development environment
- [ ] I'm comfortable contributing, but new to this project specifically

Start by locating the broker's MQTT connection entry point and the existing authorizeClient path mentioned in the issue. Review the v5 acl-connect testing context and determine how connection attempts can be rejected before TLS negotiation. Done means excessive per-IP attempts are dropped at the broker with a configurable threshold and the production-risk scenario is covered by verification.

Written by the indexing model from the issue text.