fix: handle serde duplicate field error when providers send both legacy and new usage field names

[ajianaz]

Problem

GPT-5.4 returns both legacy (prompt_tokens) and new (input_tokens) field names in the usage object simultaneously. serde_json >= 1.0.120 tracks visited fields during struct deserialization — when an alias maps to a field already set from the primary key, it raises duplicate field error, breaking all reviews using affected models.

Closes #330

Changes

Before: Usage struct used #[serde(alias = "input_tokens")] to accept both naming conventions. When both names appeared in the same JSON, serde errored.

After: Usage is now a plain struct (no serde derive). New parse_usage_value() function extracts from serde_json::Value with explicit preference order:

1. Primary: prompt_tokens → completion_tokens → total_tokens
2. CamelCase: promptTokens → completionTokens → totalTokens
3. New (GPT-5+): input_tokens → output_tokens

This handles all three scenarios:

• Legacy only (GPT-4, Claude) — works as before
• New only (some future providers) — resolved correctly
• Both (GPT-5.4) — deduplicated, no error

Both streaming (extract_stream_usage) and non-streaming (ChatResponse) code paths updated.

Tests

• 6 new tests covering all usage field naming scenarios
• All 609 existing tests pass (581 unit + 16 CLI + 6 config + 6 new)

Cora Self-Review Notes

Cora flagged 2 theoretical concerns on this PR:

1. Zero-valued legacy fields — would only matter if a provider sent prompt_tokens: 0 with input_tokens > 0. No known provider does this; GPT-5.4 sends matching values.
2. u64→u32 truncation — requires >4.2B tokens in a single request, physically impossible.

Both are acceptable trade-offs for now. Can revisit if a provider actually exhibits these behaviors.