Fix rate limiter: atomic INCR+EXPIRE with fixed window (was sliding, never expired)

[smahima27]

Bug

The rate limiter never returned 429s despite the middleware being wired correctly.

Root cause

Two bugs in the original implementation:

1. Non-atomic check-then-increment with sliding window reset

# BEFORE (broken)
def rate_limit_exceeded?(...)
  current_count = @redis.get(key).to_i   # read
  current_count >= limit
end

def increment_request_count(...)
  @redis.pipelined do |p|
    p.incr(key)
    p.expire(key, period)   # ← resets TTL on EVERY request!
  end
end

The expire was called on every request, which continuously reset the 60s window. Under rapid fire (105 requests in < 1s), the window never closed and the count kept climbing past the limit without triggering.

2. Race condition between get and incr — under concurrent load, multiple requests see count 0 before any increments land.

Fix

Increment first with INCR, only set EXPIRE on first request (count == 1) to establish a fixed window. Check the return value of INCR (which is the new count post-increment):

# AFTER (fixed)
def call(env)
  current_count = increment_request_count(client_id, endpoint_type)
  return rate_limit_response(...) if current_count.nil? || current_count > limit_for(endpoint_type)
  @app.call(env)
end

def increment_request_count(...)
  count = @redis.incr(key)
  @redis.expire(key, period) if count == 1   # ← fixed window, set once
  count
end

This ensures:

• The TTL is set exactly once per window
• The count check is based on the post-increment value (atomic)
• Request Store token metadata in vmpooler__vm__ Redis hash #101 in a 60s window returns 429