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 bought -- worse for small capacities, where "capacity 1" effectively means "always denied." It shows up as support tickets from customers who have made zero real requests, and is easy to ship unnoticed because manual testing usually checks "does it deny eventually," not "does it admit exactly N."

AllowN is supposed to allow bursts up to capacity, but the request that would exactly exhaust the bucket is rejected instead of admitted -- an off-by-one in the token-sufficiency comparison.

1. tb := ratelimit.NewTokenBucketMemory(3, 0 /* no refill */, time.Minute)
2. Call tb.Allow(ctx, "user-1") three times in a row.
3. Observe: the 3rd call returns Allowed: false, RetryAfter: 0.
4. Expected: all three calls return Allowed: true, and only a 4th call is denied.

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

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