feat: add a dashboard timeline of provider and config changes

[EricGrill]

Why

Issue #22 asks for a timeline that helps explain what changed when usage shifts.

What changed

• added a local timeline endpoint derived from queue/config/project data
• surfaced first-seen sources, first-seen models, project attribution start, and cloud sync configuration
• rendered the result as a dashboard card

Verification

• node --test test/change-timeline.test.js
• npm run validate:copy

Closes #22

[mm7894215]

Thanks for the contribution. This needs changes before merge.

The API/hook currently hardcode user-facing timeline titles and details in English, which bypasses copy.csv and breaks language switching. Please return structured event types/params from the API and render localized copy in the dashboard. Also avoid treating fetch failures as a normal empty timeline state.

[EricGrill]

Addressed review feedback:

• Structured event payload: /functions/tokentracker-change-timeline now returns { date, event_type, params } per event (source_first_seen, model_first_seen, project_attribution_started, cloud_sync_configured). It no longer embeds pre-rendered title or detail strings — those are rendered in the dashboard via copy() with {{...}} interpolation, so language switching now works.
• Error vs empty state: useChangeTimeline now exposes { events, loading, error } and ChangeTimelineCard renders three distinct states — dashboard.timeline.error (with role="alert"), dashboard.timeline.loading, and dashboard.timeline.empty. Failed fetches are no longer indistinguishable from a normal empty timeline.
• Test updated to assert that the API does not return pre-rendered titles/details and that the structured event types/params come through.

Rebased onto current main. Tests pass (node --test test/change-timeline.test.js); dashboard build is clean; validate:copy reports no new warnings.

[mm7894215]

Thanks for taking on #22 — the PR is well-scoped and the test coverage is nice to see. I'm going to close it though.

The main dashboard is tightly focused on token-usage signal (totals, trends, breakdowns, limits). A timeline of "first time we saw provider X" / "cloud sync turned on at T" is metadata about TokenTracker itself rather than about a user's usage, and I don't think it earns a top-level dashboard card. For that kind of audit info I'd lean toward surfacing it in tokentracker doctor / tokentracker diagnostics (CLI output), not the main UI.

I'll leave #22 open for now in case there's a different surface where this fits later. Appreciate the contribution.