fix(limit-count): validate variable-resolved count/time_window bounds

[shreemaan-abhishek]

Description

limit-count lets count and time_window be set from a request variable, e.g. "count": "${http_count ?? 2}". At request time the resolved string was only coerced with tonumber and checked for being a number. It was never bounds-checked, so a client-supplied value of 0, a negative, a fractional, or an out-of-range number bypassed the schema's > 0 integer constraint:

• 0/negative hit the limiter constructor's assert(limit > 0 and window > 0), turning a client header into a request-time error.
• fractional/huge values skewed the limiter's math.

This mirrors the validation limit-conn already performs on its variable-resolved conn/burst: the resolved value must be a positive integer within the safe integer range (2^53-1). Invalid values are now rejected through the normal error path instead of reaching the limiter.

limit-conn's identical gap was already fixed; this closes the same hole in limit-count.

Which issue(s) this PR fixes:

N/A (hardening; reported internally against the API7 fork)

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change (docs already state > 0; behavior now matches)
• I have verified that this change is backward compatible

[membphis]

This looks incomplete for rules mode.

The new resolve_var() validation correctly rejects zero, negative, fractional, and out-of-range count / time_window values, but get_rules() still treats errors from rule.count and rule.time_window as “skip this rule”.

As a result, when count or time_window is resolved from a client-controlled variable, an invalid value can silently disable that rule instead of rejecting the request. This leaves limit-count-advanced / rules-based configurations uncovered by the fix.

Could we return the validation error for count / time_window here, and only skip the rule when the rule key itself does not resolve?