fix(gateway): resolve unbounded DashMap memory leak in TokenBucketRateLimiter (#1609)

[vivekrajsingh04]

Description

This PR addresses a critical Denial of Service (DoS) vulnerability caused by an unbounded memory leak in the TokenBucketRateLimiter.

Previously, TokenBucketRateLimiter tracked rate limits using an unbounded DashMap. Because KeyStrategy::PerClient is supported, every unique client IP generated a permanent tracking entry in the system memory. Without any TTL or eviction mechanisms, long-running gateway instances were susceptible to encountering Out Of Memory (OOM) panics due to gradual accumulation or deliberate DoS attacks using mutating IP headers.

Fix

• Swapped DashMap for moka::sync::Cache: Replaced the unmanaged DashMap with the highly concurrent moka cache interface.
• Time-to-Idle & Capacity Bound: The cache is now aggressively guarded. Active trackers are capped at an upper-bound of 100,000 concurrent clients per node, and stale trackers are garbage collected if they remain unaccessed for 10 minutes (long enough to let standard tokens refill, but short enough to prevent memory runaway).

Performance Optimization (Zero Allocation)

As a bonus, I optimized check_and_consume() to prevent heap string allocations. Previously, passing a client key necessitated a .to_string() allocation on every authenticated request before it reached the internal entry(). Now, it performs a zero-cost self.buckets.get(key) first, allowing the gateway to breeze through repeated requests completely allocation-free.

Fixes #1609

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance improvement

Testing

• Validated thread safety with existing concurrent tests by confirming the Arc<Mutex<TokenBucket>> state accurately caps limits globally under cross-thread contention.
• Verified compilation and linting explicitly around moka cache logic.