v1.4.5 — stop rate-limit notification spam

What you saw before

When util jumped to 100%, you got 4 simultaneous notifications: ⚠️ 80% / ⛔ 95% / 🛑 100% / 🔥 burn-rate. When the 5h window rolled over, the same 4 notifications fired again — a screenshot from the user showed 8 push notifications in 10 minutes.

What v1.4.5 does

• One notification per escalation per limit. Jumping 0→100% now fires exactly one (🛑 100%).
• Window rollover no longer re-fires. State lives in {limit_key: {tier, at}}, no reset timestamp in the key. User staying at 100% across a 5h boundary gets zero additional pushes.
• Drop-and-recross re-fires correctly. If util falls below 80% and then climbs back, next crossing fires again (intentional — user actively escalated).
• Burn-rate suppressed when already blocked. Once 100% notification fires, burn-rate is redundant.
• Burn-rate math hardened. Clamps remaining_min to [0, 300] so malformed API responses can't produce false positives.

Tests

6 new regression cases covering:

• Jump 0→100 fires once
• Same-level repeat no-refire
• Window rollover no-refire
• Drop-and-recross re-fires
• Escalation through tiers (each crossing once)
• Burn suppressed at 100%

All 17 tests green.

Compatibility

Legacy state file format (pre-v1.4.5 keys like five_hour_80_<reset>) is discarded silently on first load. No migration needed. If you somehow miss a notification during the transition, util dropping and re-climbing will re-fire it.