fix(providers): don't crash on empty choices in openai and deepseek

[chiruu12]

Fixes #6715.

The OpenAI and DeepSeek providers read response.choices[0].message.content with no guard. An OpenAI-compatible backend can return HTTP 200 with an empty choices list (for example a content-filter block), so choices[0] raises IndexError and the workflow step crashes.

The same fix already landed for litellm/vllm (#6705) and grok (#6710); this covers the two remaining OpenAI-compatible providers.

Change

• Guard choices[0] in both providers and degrade to an empty string, matching the grok and litellm behavior.
• Add a test for each provider that patches the client to return empty choices and asserts _query returns {"response": ""} instead of raising.

Validation

poetry run pytest tests/providers/openai_provider/test_openai_empty_choices.py \
  tests/providers/deepseek_provider/test_deepseek_empty_choices.py
poetry run ruff check keep/providers/openai_provider keep/providers/deepseek_provider

Both tests pass on this change and fail with IndexError on the current code (openai_provider.py:69, deepseek_provider.py:83), so they pin the regression. ruff clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 30.46%. Comparing base (ce302f6) to head (eca7d6c).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #6716       +/-   ##
===========================================
- Coverage   46.42%   30.46%   -15.96%     
===========================================
  Files         178      101       -77     
  Lines       18694    11773     -6921     
===========================================
- Hits         8679     3587     -5092     
+ Misses      10015     8186     -1829     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[chiruu12]

The run-mysql-with-redis / run-tests failure here is not coming from this change. The backend dies on startup with Unknown column 'provider.pulling_enabled' in 'field list', which is a MySQL schema mismatch, and #6714 is failing the same way right now. This PR only touches response parsing in the openai and deepseek providers, so it has no models or migrations in it. Happy to rebase once that is sorted out.

[chiruu12]

Rebased onto current main at ea3bc8e. That cleared the MySQL failure I flagged above:
run-mysql-with-redis now passes in 22m57s and run-postgresql-without-redis passes
too, so the provider.pulling_enabled schema mismatch was a stale test environment
rather than anything in this branch.

What is left is one red job, run-sqlite-without-redis, failing in "Run e2e tests and
report coverage". I do not think it is this diff. The E2E workflow is failing on a
different database variant per run across unrelated branches: run 32520920202 on
fix/foreach-falsy-scalar-6721 failed MySQL and passed SQLite, and this run is the
exact opposite. A change that only touches response parsing in the openai and deepseek
providers should not be able to pick which backend breaks.

Unit tests, integration tests, workflow examples and docs are all green.

Could someone re-run the failed job? I cannot trigger it from a fork.