fix(providers/openai): accept streaming chunks with both reasoning fields

[capttrousers]

Summary

Some OpenAI-compatible servers (notably vLLM serving gpt-oss-120b, see vllm-project/vllm#27755) emit both reasoning and reasoning_content in the same chat.completion.chunk delta, usually mirroring each other:

{"choices":[{"delta":{"reasoning":"","reasoning_content":""}}]}

The streaming Delta struct used #[serde(alias = "reasoning")] on reasoning_content, so serde treated the two keys as duplicates of the same field and failed the whole stream parse with:

Request failed: Failed to parse streaming chunk:
  duplicate field `reasoning_content`

This splits reasoning and reasoning_content into two separate Option<String> fields on Delta and reads them through a new reasoning_text() helper that prefers reasoning_content (DeepSeek/OpenRouter convention), falls back to reasoning (vLLM), and skips empty values. The non-streaming response_to_message path already tolerated both fields via a manual .get().or_else() fallback — this brings the streaming path to parity.

The two commits are structured for TDD: the first adds tests (one of which fails on that commit with the duplicate-field error); the second is the fix that flips it to green.

Testing

• cargo test -p goose --lib providers::formats::openai — all tests pass after the fix; the new test_streaming_chunk_with_both_reasoning_fields fails on the test-only commit as designed.
• cargo fmt
• cargo clippy --all-targets -- -D warnings
• Manual: configured goose CLI against a local vLLM-hosted gpt-oss-120b endpoint and confirmed chat + tool-call streaming no longer errors.

Related Issues

No open goose issue — discovered while configuring goose against a local vLLM gpt-oss-120b endpoint. Upstream vLLM context: vllm-project/vllm#27755.

[lifeizhou-ap]

Thank you for the contribution!