fix: handle None choices in ChatCompletion response

[Spectual]

Summary

Fixes #604

Some LLM providers (e.g. OpenRouter, proxies under rate-limit or authentication failure) return an error payload where the choices field is None rather than raising an HTTP-level error. Previously, this caused the SDK to crash with an opaque TypeError: 'NoneType' object is not subscriptable deep inside openai_chatcompletions.py, before the calling application had any chance to inspect the actual provider error.

Changes

• Added a guard clause in OpenAIChatCompletionsModel.get_response() that checks response.choices before any access to choices[0].
• When choices is None or empty, a ModelBehaviorError is raised with a clear message. If the response object carries an error field (as provider error payloads typically do), that information is included in the exception message.
• This makes the failure mode explicit and catchable, allowing callers to log the real provider error or trigger retry logic.

Root cause

openai_chatcompletions.py assumed every successful API call would return at least one choice. Providers that surface errors as JSON bodies (rather than HTTP error codes) return a ChatCompletion-shaped object with choices=None, triggering the crash.

Test plan

• Reproduce with a dummy key pointed at a provider that returns an error payload (e.g. OpenRouter with an invalid key) — confirm ModelBehaviorError is raised instead of TypeError.
• Verify existing unit tests pass (pytest tests/).
• Verify that normal completions (choices present) are unaffected.

[seratch]

Can you resolve the format issue?