Add menubar cost/tokens toggle

[ozymandiashh]

Summary

Rebases the menubar Cost/Tokens toggle onto current main and keeps the original #305 behavior intact after the CLI split and daily-cache changes.

This lets users switch the same menubar surface between dollar cost and total token traffic when tokens are the more useful signal, especially on flat-rate plans.

Closes #305.

What changed

• Add a persisted Cost | Tokens headline metric in the macOS menubar app.
• Apply the selected metric to the hero headline, Activity row value/bar scaling, and always-visible macOS status item number.
• Extend the menubar JSON payload with current-period cache read/write token totals and per-activity input/output/cache read/cache write token totals.
• Preserve legacy payload decoding by defaulting newly added token buckets to 0.
• Store per-category token totals in the daily cache so historical all-provider periods can render Tokens mode without reparsing raw sessions.
• Bump daily cache to v8. Current main is already v7, and v7 entries still lack per-category token totals, so older cache files are backed up and rebuilt cleanly.
• For provider-filtered menubar periods, parse the selected period directly instead of using the provider cost/calls cache fast-path, because the cache does not store provider-scoped token buckets.
• Update README/changelog and regression coverage.

Validation

• npx vitest run - 60 files / 861 tests passed.
• npx vitest run tests/menubar-json.test.ts tests/day-aggregator.test.ts tests/daily-cache.test.ts - 42/42 tests passed.
• npm run build - passed.
• swift build - passed.
• git diff --check - passed.
• Argus-style local reviewer - PASS.
• Claude Opus 4.7 effort max review - PASS, no required fixes.
• Gemini 3.1 Pro Preview review - PASS, no required fixes.

Notes

• swift test --filter MenubarPayloadTests is still blocked locally by the existing Swift test-target/toolchain issue: no such module 'Testing' in existing test files.
• Provider-filtered Tokens mode now favors accuracy over the previous cache fast-path. Long provider-filtered periods may refresh more slowly, but they avoid showing partial token totals.
• No local project names, prompts, paths, session IDs, usage values, or private product details are included here.

[ozymandiashh]

Validation run on macOS arm64 with real local usage data. No project names, prompts, paths, session IDs, or internal product details are included here.

Commands run:

• swift build from mac/
• npx vitest run tests/menubar-json.test.ts tests/day-aggregator.test.ts
• npx tsx src/cli.ts status --format menubar-json --period today --provider all with structural jq checks only

Results:

• Swift app target builds successfully.
• Targeted JS tests passed: 26/26.
• Real menubar-json payload parsed successfully.
• Payload includes top-level token totals: input, output, cache read, cache write.
• Activity/category rows include token fields, so the Cost/Tokens toggle has the data it needs.

Swift unit tests were not used for this validation because the current local Swift test target is blocked by the pre-existing no such module 'Testing' issue in CapacityEstimatorTests.swift.

[ozymandiashh]

Visual validation for #307 after the latest rebase and token-total fix.

Update after contributor review: the earlier screenshot showed inflated token totals because Tokens mode was including cache read/write buckets. That screenshot has been replaced.

Follow-up fix pushed in 85a32fd:

• Menubar Tokens mode now follows standard CodeBurn usage semantics: input + output tokens only.
• Cache read/write buckets are still decoded and preserved in the payload for cache metrics/debugging.
• Status item, hero, trend, and Activity rows now use the same token definition.

Validation/proof:

• npx vitest run tests/menubar-json.test.ts tests/day-aggregator.test.ts - 26/26 tests passed.
• npm run build - passed.
• swift build - passed.
• git diff --check - passed.
• GitHub checks (assess, check, semgrep) - passed.
• Argus-style review - PASS.
• Claude Opus 4.7 effort max review - PASS.
• Gemini 3.1 Pro Preview review - PASS.

Swift unit tests were not used for the final proof because the current local Swift test target is blocked before filtered tests run by the existing unrelated no such module 'Testing' issue.