fix: guard LLM response access in 39 cookbook examples

[qizwiz]

Summary

response.choices[0].message.content is typed Optional[str] in the OpenAI SDK — it returns None (not raises) when the provider applies content filtering or when finish_reason is "tool_calls". Every unguarded .content access in the cookbook is a latent crash site.

This PR adds a uniform three-layer guard before every unguarded access across all 39 cookbook utility files:

if not r.choices or r.choices[0].message is None or r.choices[0].message.content is None:
    raise ValueError("LLM returned empty or filtered response")
return r.choices[0].message.content

Anthropic calls are guarded analogously (len(response.content) == 0 / .text is None).

Files changed: all cookbook/*/utils.py and cookbook/*/utils/call_llm.py files — 39 files, 138 insertions.

Why this matters

The OpenAI SDK types ChatCompletionMessage.content as Optional[str]. The silent None return propagates downstream — the crash happens far from the API call, often in user-facing code, with a confusing TypeError: argument of type 'NoneType' is not iterable or similar message.

Test plan

• Verify each patched call_llm raises ValueError when given a mock response.choices = []
• Smoke-test one example end-to-end to confirm guard doesn't fire on normal response

🤖 Generated with Claude Code