fix(responses): handle null text values in output_text property

[Vitalcheffe]

What

Fixes Response.output_text to handle null text values in content items, preventing a TypeError when concatenating output text.

Why

When the API returns a response where an output_text content item has text: null (observed with openai/gpt-oss-safeguard-120b and potentially other models), accessing response.output_text raises TypeError: sequence item 0: expected str instance, NoneType found.

See: #3011

How

1. response.py: Added a content.text is not None guard before appending to the texts list in the output_text property. Content items with null text are silently skipped.
2. response_output_text.py: Changed text: str to text: Optional[str] = None to accurately reflect that the API can return null for this field.
3. test_responses.py: Added two regression tests:
   • test_output_text_with_null_text — verifies no crash when all text is null
   • test_output_text_mixed_null_and_text — verifies null items are skipped while valid text is concatenated

Testing

• ruff check passes on all modified files
• Regression tests cover both all-null and mixed null/text scenarios

Checklist

• Tests added
• Linter passes
• No breaking change (property still returns str, null items are simply skipped)

Closes #3011

[Vitalcheffe]

Note on the type change: ResponseOutputText.text moving to Optional[str] is technically a widening change — existing code that already handles the output_text property (via the joined string) is unaffected. The type change only impacts code that directly accesses .text on individual content items, which the SDK docs don’t expose as a primary API. Happy to add a deprecation note or keep str with an internal cast if preferred.
Note on silent skip: The null items are skipped silently to match the behavior of other SDK properties that return best-effort aggregations. If a warning via logging is preferred, I can add that.

[Vitalcheffe]

Also worth noting on the silent skip behavior: null text items are skipped silently to match the best-effort aggregation pattern used elsewhere in the SDK (e.g. output_text already concatenates across multiple content blocks without raising on empty). If a logging.warning() is preferred when null items are encountered, I can add that — just let me know the preferred approach.