Prevent WidgetKit reload loop in BurnDownRefreshSchedule (fix #2369)

[Yuxin-Qiao]

This PR prevents a WidgetKit reload loop where the widget daemon chronod sustained high disk writes when a provider's rate limit reset time was calculated very close to now (e.g. within a few seconds).

To fix this, we've enforced a minimum 5-minute reload interval safety threshold (per Apple's recommendation) on all dynamic timeline refreshes.

Changes

• Enforced minimumInterval = 5 * 60 in BurnDownRefreshSchedule.nextRefresh.
• Added test coverage for clamping behavior in CodexBarWidgetProviderTests.swift.

Verification

• Focused and sharded unit tests passed successfully.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: Prevent WidgetKit reload loop in BurnDownRefreshSchedule (fix #2369) This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 83b6b91f05

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Coalesce upcoming resets after the 5-minute floor

When one window resets inside the new floor and the other resets just after it (for example primary at now + 60s and secondary at now + 310s), clamping the already-minimized reset returns now + 300s, which is before the secondary reset. The next timeline pass then sees that secondary reset only 10 seconds away and clamps again by another five minutes, so the combined/standard widgets can show the old secondary state for nearly five minutes after the reset; choose the first reset at or after the floor, or coalesce resets inside it, instead of clamping only the earliest one.

Useful? React with 👍 / 👎.

[steipete]

Merged after a final exact-head review of 83b6b91f05370857a891f1bc229b4063253443b2 found no blocking defects. The scheduler change is narrow: reset-driven WidgetKit timeline refreshes now have a five-minute minimum while retaining the existing 30-minute fallback and the reset+1s behavior outside that minimum window.

Verification:

• All nine hosted checks passed on the exact head, including both macOS Swift test shards, lint, Linux builds, and security checks: https://github.com/steipete/CodexBar/actions/runs/29818995941
• The focused scheduling coverage exercises both the clamped near-reset case and an unclamped reset beyond five minutes.
• Structured autoreview reported no accepted/actionable findings.
• A local focused test build was also attempted, but did not reach test execution because the linker hit ENOSPC; the exact-head hosted macOS shards are the completed test proof.

Thank you, @Yuxin-Qiao, for the focused fix and regression coverage.