Propagate output_tokens_details onto the accumulated streaming Message

[camposvinicius]

Problem

The streaming accumulator copies most usage fields from message_delta onto the accumulated Message, but it never copies output_tokens_details. That field carries the reasoning token breakdown (thinking_tokens) the API reports for extended-thinking responses.

As a result the final snapshot from a stream disagrees with the equivalent non-streamed Message. A caller reading stream.get_final_message().usage.output_tokens_details gets None even when the API reported the breakdown, so cost and reasoning-token observability is silently lost on the streaming path.

MessageDeltaUsage (and the beta variant) already declares output_tokens_details, and the API sends it on message_delta. The repo's own fable-fallback fixtures carry it, for example "output_tokens_details":{"thinking_tokens":67}.

This is the same class of gap that #1725 fixed for stop_details in the same message_delta branch.

Fix

Propagate output_tokens_details from message_delta onto the accumulated snapshot in both lib/streaming/_messages.py and lib/streaming/_beta_messages.py, mirroring the existing stop_details and server_tool_use propagation.

Tests

The refusal_response.txt streaming fixture now carries output_tokens_details on its message_delta, and assert_refusal_response in both test_messages.py and test_beta_messages.py asserts it reaches the final message. The four refusal tests (sync and async, beta and non-beta) fail without the fix and pass with it. ruff and pyright are clean on the changed files.