Configurable menubar status period

[ozymandiashh]

Summary

• add a persisted CodeBurnMenubarPeriod setting for the macOS status item, with Settings choices for Today, Week, Month, and 6 Months
• keep the popover's period/provider filters independent from the always-visible menubar metric, so users can inspect one range while the status item continues tracking their chosen range
• refresh the selected menubar period on startup, manual refresh, wake/distributed refresh, and the 30-second background loop without reintroducing the old hard-coded Today path
• append compact period suffixes for non-today values ($42 / wk, $42 / mo, $42 / 6mo; compact mode uses $42/wk, $42/mo, $42/6mo)
• document the Settings behavior and Terminal override (defaults write org.agentseal.codeburn-menubar CodeBurnMenubarPeriod -string month), and add a changelog entry
• add focused Swift tests for allowed picker periods, persisted defaults mapping, invalid/default hardening, and suffix rendering

Closes #291.

Details

The old implementation treated todayPayload as special for the status item, regardless of which period the user had selected in the popover. This PR replaces that hard-coded status metric with a separate menubarPeriod in AppStore, loaded from UserDefaults on launch and persisted under CodeBurnMenubarPeriod.

The status item still uses all-provider totals, but now it reads menubarPayload instead of todayPayload. The refresh path was centralized through refreshUsagePayloads(force:showLoading:), which avoids duplicate work when the popover is already showing the same all-provider period and quietly fetches the configured status period when the visible popover state differs.

The Settings picker intentionally exposes only the four values requested in the issue: Today, Week, Month, and 6 Months. The existing popover still keeps its 30 Days segment, but 30days is not accepted as a persisted status metric; malformed or unsupported defaults fall back to Today.

Validation

• swift build
• npm run build
• npx vitest run (47 files / 661 tests)
• git diff --check
• Argus local reviewer: PASS
• Claude Opus 4.7 effort max: PASS
• Gemini 3.1 Pro Preview: PASS

Note

swift test still fails locally before running tests because the Swift test target cannot import the Testing module, including the pre-existing CapacityEstimatorTests.swift import. The app target itself builds successfully with swift build.