Stats panel: Active days, heatmap, and streak use session-creation date instead of per-message timestamps

Summary

When a single session spans multiple calendar days (via context compression and continuation), the Active days counter, heatmap, and streak only register the day the session file was first created — not each day a user message was sent within that session. The total tokens and the Models bar chart correctly use per-message timestamps, creating an inconsistency within the same stats panel.

Environment

• Claude Code Desktop for Windows
• Version: 2.1.177
• OS: Windows 11 Home 10.0.26200

Steps to reproduce

1. Start a session on Day 1 and send messages. Active days = 1.
2. The session reaches context limit and is compacted — the same session JSONL file continues.
3. Return on Day 2, Day 3, Day 4, etc. and continue working in the same session.
4. Open the stats panel (Overview tab, All time).

Expected behaviour

Active days = N (one per calendar day with at least one sent message).
Heatmap squares lit for each of those N days.
Streak counts consecutive days with messages.

Actual behaviour

Active days = 1 (the session-creation date only).
Heatmap shows a single square on the session-creation day.
Streak = 0 despite daily use.
Sessions count = total JSONL files (correct, but all "dated" to creation day).

Data confirming messages exist on all days

One session (6d542349) contains user messages on 5 different dates:

| Date | Lines with timestamps |
|------------|-----------------------|
| 2026-06-13 | 986 |
| 2026-06-14 | 1400 |
| 2026-06-15 | 3228 |
| 2026-06-17 | 1479 |
| 2026-06-18 | 41 |

Yet the stats panel shows: Sessions 2, Active days 1, Heatmap 1 square.

The Models bar chart DOES show Jun 13/14/15 bars correctly (reads per-message timestamps). The inconsistency is localised to the Active days / heatmap / streak metrics, which appear to key off session-file creation date rather than message timestamps.

Suggested fix

For Active days, heatmap, and streak: scan all timestamp fields in every JSONL session file and use the set of unique calendar dates, not the creation date of the file itself. The token-chart logic already does this correctly and can serve as a reference implementation.

Workaround

Creating one minimal stub JSONL file per missing day (a single user event with the correct timestamp, valid UUID filename) causes the stats panel to register those days correctly. This confirms the panel reads the first user-event timestamp from each file for date attribution — changing to a full scan would fix the issue without requiring workaround files.

Reported by: @sohan1611