fix: account for cached prompt tokens in OTEL spans

[simonvdk-mistral]

Summary

• emit gen_ai.usage.cache_read.input_tokens when cached prompt token counts are present in usage payloads
• support the current payload shapes exposed by the SDK and API (prompt_tokens_details.cached_tokens, prompt_token_details.cached_tokens, and num_cached_tokens)
• add non-streaming and streaming OTEL regression tests for cached token usage

Testing

• uv run pytest src/mistralai/extra/tests/test_otel_tracing.py -k 'cached_prompt_tokens or num_cached_tokens or streaming_chat_completion_enriches_span or test_chat_completion_basic'
• uv run ruff check src/mistralai/extra/observability/otel.py src/mistralai/extra/tests/test_otel_tracing.py

Linear: OBS-1423

[simonvdk-mistral]

How did you arbitrate the priority between the two (prompt token details and number of cached tokens) ?

[simonvdk-mistral]

I made the priority explicit in code in b6cce3d: prefer prompt_tokens_details.cached_tokens when present, and only fall back to top-level num_cached_tokens for payloads that expose the legacy field instead.

[simonvdk-mistral]

Ok maybe the spec is not dry yet. The UsageInfo model I linked in the linear ticket is specific to a voice endpoint, and all other endpoints (chat completion, conversation, etc) do not have the cache tokens attributes defined yet in the models.

Let's wait a bit for this PR, will come back later

[simonvdk-mistral]

Understood. I am not making a follow-up code change from this comment. The current branch only records gen_ai.usage.cache_read.input_tokens when the raw usage payload actually contains one of the cache-token fields, so endpoints whose generated models do not expose those fields today remain unaffected. I will leave the PR here and wait for your follow-up on whether you want to keep or revert this behavior once the models/spec settle.