Sliding window can deadlock permanently for a key

This is the hardest class of production incident to catch: one specific customer/key silently hangs forever, with no error, no alert, and every system-wide dashboard looking perfectly healthy. Support hears "your API just hangs for us" while on-call sees nothing wrong -- that mismatch alone can burn hours or days before anyone even suspects a single-key deadlock, let alone finds the exact oversized-request-during-rollover trigger. The cost isn't just the affected customer's downtime; it's the disproportionate engineering time spent diagnosing a bug that gives almost no observable signal to go on.

A "defensive" early-return was recently added to SlidingWindowMemory.AllowN to reject oversized single requests (n bigger than the whole configured limit) before they can pollute the window bookkeeping. It returns before unlocking the mutex it's holding. Any request that hits this branch leaves that key's rollover lock permanently held -- every subsequent call for that same key (from any goroutine) blocks on e.rolloverMu.Lock() forever.

sw := ratelimit.NewSlidingWindowMemory(5 /* limit /, 100time.Millisecond /* window */, time.Minute) sw.Allow(ctx, "user-1") // first-ever call, establishes windowStart, fine time.Sleep(150 * time.Millisecond) // now well into the next window sw.AllowN(ctx, "user-1", 999) // n=999 > limit=5, AND a rollover is due sw.Allow(ctx, "user-1") // got: hangs forever -- the rollover mutex was leaked by the early return above // want: returns promptly, whatever the outcome of the oversized request was

An unreleased lock on a per-key mutex doesn't crash anything visibly -- the process keeps running, other keys keep working fine, /healthz stays green -- but that one key is now permanently wedged: every future request for it hangs until it times out upstream (or forever, if nothing upstream has a timeout). In a real deployment this is one of the nastier classes of bug to diagnose, because nothing errors; requests for one specific key just never complete.

The safest general fix for "a critical section might return early on any number of branches added later" is the same pattern already used everywhere else a mutex guards a function in this package (token_bucket.go, leaky_bucket.go): acquire the lock, then immediately defer the unlock, so every return path -- including ones added after you fix this bug -- is covered automatically. sliding_window.go's rollover section is the one place in the package doing manual (non-deferred) lock/unlock; consider whether that was ever actually necessary here.