fix(llm): surface the response body when a completion has no choices

[wmeddie]

Two resilience fixes in the OpenAI adapter's response handling, both observed with OpenAI-compatible gateways in production use.

1. A completion without choices now raises a useful error

Some OpenAI-compatible gateways return upstream error bodies (rate limits, provider failures) with HTTP 200. The SDK constructs those leniently, so choices ends up None/absent and response.choices[0] raises a bare 'NoneType' object is not subscriptable — the actual upstream error (sitting right there in the body) never reaches the caller or the logs.

OpenAILLM.generate now checks before subscripting and raises a RuntimeError carrying the response body (truncated to 500 chars):

RuntimeError: LLM API returned a completion without choices: {"code": "rate_limit_daily", "message": "Error code: 429 - ..."}

The streaming path already guards (if chunk.choices and ...), so only generate needed it.

2. Tool-call argument parsing tolerates recoverable malformations

The strict json.loads in the tool-call path dropped two recoverable cases (skipping the call with only a log line):

• raw control characters (literal newlines) inside JSON string values — models emit these routinely, and strict=False parses them fine;
• empty arguments from parameterless tool calls — json.loads("") raises, but the right reading is {}, not dropping the call.

Truly irrecoverable arguments (garbage, non-dict JSON like a bare list) keep the existing skip-with-warning behavior from #33; a bare non-dict additionally can't crash LLMFunctionCall validation anymore.

Tests

test_openai_no_choices.py (incl. the SDK's real lenient construct() path) and test_openai_tool_arguments.py.

Note: commit 70f52e6 on the already-merged #35 branch is a stray push of the first fix made before noticing the merge — ignore that branch head; this PR supersedes it, rebased onto current main (composes with the finish_reason handling from #33).