fix(limit-count): commit() must report the window-weighted remaining

[nic-6443]

Description

commit() in the sliding-window limiter reports limit - current_count as the remaining quota, while incoming() reports the window-weighted value (limit - current_count - last_count * remaining_time / window). Delayed sync (sync_interval) flushes locally-permitted deltas through commit() and caches the reported remaining as the global quota for the next interval, so at every window boundary each gateway instance starts again from a nearly full budget: the sliding window effectively degrades into a per-window fixed window.

The effect is easy to measure: 2 instances sharing one Redis, count=500, time_window=1, window_type=sliding, sync_interval=0.2, sustained 800 rps for 30s. Ideal admission is 500/s. Before this change the gateways admit ~590/s (+18% over the limit, bursty at each window start); with this change they admit ~438/s and converge, matching what the pre-#13443 flush path (which used incoming() for flushing) produced. The remaining gap below the limit is the inherent cost of the delayed-sync snapshot, not new behavior.

The fix reads the previous window counter after the increment and reports the same weighted remaining as incoming(). A failed read must not fail the commit — the delta is already recorded, and the delayed syncer would retry and double-count it — so it degrades to the unweighted remaining and logs instead.

The unconditional increment behavior from #13443 is unchanged: only the reported remaining is corrected.

Which issue(s) this PR fixes:

Introduced in #13443.

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 (no documented behavior changes)
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

[membphis]

For Redis-backed sliding-window limits, we strongly recommend enabling delayed sync (sync_interval). It batches counter updates instead of accessing Redis on every request, greatly reducing Redis pressure and generally improving overall stability and performance. With delayed sync enabled, the additional previous-window lookup occurs only during synchronization, not on every request.

[membphis]

LGTM