fix(providers): guard against empty choices list in openai and deepseek providers

[Prabal864]

Fixes #6715.

Both the OpenAI and DeepSeek providers read response.choices[0].message.content without checking that choices is non-empty. An OpenAI-compatible backend can return HTTP 200 with an empty choices list (e.g. a content-filter block), which raises IndexError and fails the workflow step instead of degrading — same failure already fixed for litellm/vllm in #6705 and for grok in #6710, these two providers weren't covered.

Guards the access with try/except and falls back to an empty string, matching the grok/litellm/vllm behavior.

Added tests for both providers covering the empty-choices case and the normal-response case, mocking the OpenAI SDK client directly since these two providers go through the SDK rather than raw requests calls.

[CLAassistant]

All committers have signed the CLA.

[chiruu12]

@shahargl this duplicates #6716, which has been open against #6715 since 20 Aug and is linked from it.

• 20 Aug 10:52, I opened openai and deepseek providers crash on an empty choices list #6715
• 20 Aug 10:58, I opened fix(providers): don't crash on empty choices in openai and deepseek #6716, linked as Fixes #6715
• 21 Aug 09:11, comment on the issue asking to take it
• 21 Aug 09:43, this PR

Your call which one goes in, so here is the state of each. #6716 has run the full matrix. sqlite, postgres, integration and unit are all green. The one red job is run-mysql-with-redis, and that is the backend container refusing to boot with Unknown column 'provider.pulling_enabled' in 'field list', which is a schema problem on main rather than anything in the diff. It fails the same way on #6714 from a different author. This PR has not run a test job at all yet. Its five checks are CLA, PR title, issue link, GitGuardian and CodeRabbit.

One other thing worth flagging. The inline comment added here is a light rewording of the one in #6716, and the two test files reuse the helpers and test names from tests/providers/grok_provider/test_grok_response_parsing.py, which I wrote in #6710. Reusing merged code is normal and fine. An open PR that is already linked from the issue is a different thing.

[Prabal864]

Fair point on the timing — #6716 was open and linked well before I got here, closing mine in favor of it.

One clarification on the code overlap, since it's worth stating plainly: I mirrored the pattern from the merged grok fix (#6710), not from #6716 — I hadn't looked at #6716's diff until you flagged this. The wording is close because we're both paraphrasing the same source for the same bug, but a couple of things differ if you want to check — my except clause also catches AttributeError, and my test filenames follow grok's existing _response_parsing naming convention rather than a new one. Not trying to make a thing of it, just didn't want it left unaddressed.