Stale rate-limit cache blocks the worker after quota reset

Summary

The worker can remain blocked by an old rejected rate-limit bucket after the provider quota window has reset.

Failure mode

A newer rate_limit_event can include a fresh unifiedWindows snapshot showing that a window is available again, while RateLimitStore still retains a prior rejected entry for that window. shouldAbortForQuota then aborts before the next generation attempt. Reset timestamps may also arrive in epoch seconds, so comparing them as raw milliseconds prevents stale entries from expiring.

The result is that the in-memory observation queue keeps growing even though the provider reports usable quota.

Expected behavior

• Fresh unified-window snapshots replace the corresponding cached buckets, including stale rejection state.
• Rejection and utilization state stops blocking once its reset timestamp has elapsed.
• Active quota limits continue to stop background generation.

Scope

Add focused coverage for unified-window cache replacement, expired rejections, and epoch-second reset timestamps.