fix: deduplicate token metrics by message.id to prevent multi-counting

[KorenKrita]

Problem

Claude Code writes one JSONL transcript entry per content block within a single API response. A typical assistant turn with thinking + text + tool_use produces 2–4 JSONL rows, each carrying:

• The same message.id
• A full copy of the usage snapshot (identical input_tokens, output_tokens across all rows)
• A non-null stop_reason (e.g. "tool_use" or "end_turn")

Both getTokenMetrics and collectSpeedMetricsFromLines sum every assistant row that has a usage field without checking whether multiple rows belong to the same API response. This causes token counts and speed metrics to be inflated by 1.4–2.5× depending on the average number of content blocks per turn.

The existing stop_reason-based dedup in getTokenMetrics does not help because all rows from the same response carry the same non-null stop_reason.

Measured impact (real transcripts)

Metric	Before fix	After fix	Inflation factor
requestCount	114	61	1.87×
outputTokens	69,720	29,888	2.33×
outTps	85.5 t/s	36.6 t/s	2.34×

Verified across 20 models with 50k+ assistant rows — all affected (1.36×–2.46× depending on model's tendency to produce multi-block responses).

Fix

Deduplicate by message.id in both code paths:

1. collectSpeedMetricsFromLines (speed metrics): maintain a Map<messageId, SpeedRequest>. First row per id seeds the request with usage and interval. Subsequent rows for the same id only extend interval.endMs to the turn's final timestamp. Rows without a message.id fall back to per-row counting.

2. getTokenMetrics (token totals): single-pass filter that applies both the existing stop_reason check and a Set<messageId> dedup, keeping only the first row per id.

3. TranscriptLine type: add optional id?: string to message.

Testing

• All 1,589 existing tests pass
• Verified against real transcripts: deduplicated requestCount matches the actual number of unique turns (confirmed via message.id grouping)
• Smoke-tested full statusline rendering with patched build