Omitting "n" in /api/v1/check now returns 500

This breaks the single most common call shape of the service's primary API -- every documented example, and almost certainly every real integration, omits n. Shipping this turns on an immediate, broad outage of /api/v1/check for essentially all normal traffic (a 500, not a graceful denial), the moment it reaches production. Any downstream service that depends on this endpoint for admission control would start failing closed or failing open depending on how it handles a 500 -- either way, an incident, not a degraded edge case.

Per the README, n in the /api/v1/check request body is "optional, default 1." The overwhelming majority of real calls (and every example in the README) omit it entirely. Those calls are now failing.

Build a checkRequest from JSON {"rule":"free-tier","key":"user-123"} (no n field -- Go's JSON decoder leaves req.N at its zero value, 0). Call handleCheck. // got: a 500 response // want: a 200 response, identical to sending "n": 1 explicitly

Omitting n is not an edge case here, it's the default and by far the most common call shape (it's the one used everywhere in the README and in the seeded demo routes' implicit Allow calls). A regression here would 500 out essentially every /api/v1/check request that follows the documented usage until someone starts explicitly sending "n": 1 as a workaround -- exactly the kind of "worked in my testing, breaks for real traffic" bug that a narrow manual test (always sending n explicitly) would miss entirely.

handleCheck already has logic meant to default a non-positive n to 1 before calling limiter.AllowN. Check the exact boundary condition of that default against what "the zero value of an omitted int64 JSON field" is, and against what AllowN itself considers invalid input (errors.New("ratelimit: n must be positive")).