fix: chat_json reports truncation instead of "unparseable response"

[hherb]

Symptom

When a chat_json response is cut off at the max_tokens ceiling, the JSON can't parse, so the agent retries the identical request up to 3 times (paying for each truncated generation) and finally raises a misleading ValueError: Failed after 3 attempts: unparseable response. This cost a full debugging loop in evidenceseeker (cairn-ehr/evidenceseeker#8) before the real cause — the 4096 default budget — was found.

Fix

• chat_json now checks response.stop_reason against truncation markers ("max_tokens" for Anthropic, "length" for OpenAI-compatible) when the content doesn't parse:
  • temperature 0: raise immediately — greedy sampling provably reproduces the identical truncation, so retries only pay for it again.
  • temperature > 0: keep the normal retries (a retry may sample a shorter completion that fits — existing callers on tight budgets like study_classifier/quality_agent rely on that recovery), but the final error names truncation and the budget instead of "unparseable response".
• Truncation is checked before the empty-content branch, so a budget consumed before any visible text (e.g. by thinking tokens) reports as truncation, not "empty response from model".
• The truncated output is logged at ERROR, matching the unparseable branch.
• A response that parses despite hitting the ceiling is returned as usual.
• Ollama provider: surface done_reason="length" as stop_reason instead of hardcoding "stop" — previously truncation was invisible for every ollama-backed agent, so the new detection could never fire for them.

Verification

• 21 tests in tests/test_agents.py (6 new: parametrized greedy fail-fast, nonzero-temperature retry-then-name-cause, recovery on shorter retry, empty+truncated, parseable-despite-ceiling) and 8 in tests/test_llm.py pass; ruff clean on touched files.

🤖 Generated with Claude Code