Token bucket denies a request that exactly matches remaining tokens

Token bucket backs the pro-tier plan (and any small-capacity policy, e.g. "1 password reset email per key at a time"). Losing the last unit of every configured burst means paying customers systematically get less throughput than the plan they're sold -- worse for small capacities, where "capacity 1" effectively means "capacity 0, always denied." That shows up as support tickets ("your API says I'm rate-limited but I've made zero requests"), erodes trust in the pricing tiers, and is the kind of quietly-wrong behavior that's easy to ship unnoticed because most manual testing checks "does it deny eventually," not "does it admit exactly N."

TokenBucketMemory.AllowN is supposed to allow bursts "up to capacity" (see the package doc and the README's algorithm table). In practice, the last request that would exactly exhaust the bucket is being rejected instead of admitted.

tb := ratelimit.NewTokenBucketMemory(3, 0 /* no refill */, time.Minute) tb.Allow(ctx, "user-1") // call it 3 times in a row // got: the 3rd call returns Allowed: false, RetryAfter: 0 // want: all three calls return Allowed: true; only a 4th call should be denied

Any caller relying on "capacity N means N requests get through" silently loses one unit of their configured burst allowance. For a small capacity (e.g. capacity 1, used to gate a single in-flight operation per key) this means the feature never actually admits anything.

The bug is a single comparison operator inside AllowN's token-sufficiency check. Re-derive, from the doc comment above the function and the README's description of "allows bursts up to a capacity," what the boundary condition (tokens == n) should do, and compare that to what the current operator does. Do not change the refill math or the Remaining/ResetAt calculations -- only the admission check is wrong.