fix(usage): Normalize None token details on Usage initialization

[codefromthecrypt]

Some openai API clones (such as ollama) don't populate new token detail fields, resulting in None values that bypass Pydantic validation. This results in agent crashes like this:

    ^
  File "/Users/codefromthecrypt/.cache/uv/environments-v2/agent-ce802ac7ec8719af/lib/python3.14/site-packages/agents/run.py", line 1740, in _get_new_response
    context_wrapper.usage.add(new_response.usage)
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
  File "/Users/codefromthecrypt/.cache/uv/environments-v2/agent-ce802ac7ec8719af/lib/python3.14/site-packages/agents/usage.py", line 76, in add
    cached_tokens=self.input_tokens_details.cached_tokens
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + other.input_tokens_details.cached_tokens
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

This fix adds a __post_init__ method to normalize None to 0 for "cached_tokens" and "reasoning_tokens" on any Usage object creation. This defensive approach handles the issue at the boundary we control (just after the stainless generated code), allowing absence of these newer fields to not break agents.

[codefromthecrypt]

FYI I'm aware it could be a bikeshed discussion if these fields are really optional or not. for example, they are more or less implied or explicitly required in the latest openai openapi yaml. However, there is defensive code around other token fields, that coerce to zero. Plus the impact is tricky to workaround otherwise even if PRs are raised everywhere. So, hoping we can add similar defense here

[seratch]

We'e fine to deal with this reality, but can you update the code comment a bit more for future maintainers?

[seratch]

Thank you!