refactor(llm): chain exceptions in client error handlers (ruff B904)

[CGFixIT]

Summary

LocalLLMClient.generate and GrokClient.generate re-raise LLMServiceError / GrokServiceError from inside their except blocks without from, discarding the original exception's context (__cause__). The project's own ruff config selects the B rule family (pyproject.toml → [tool.ruff.lint] select = [..., "B", ...]), so these are six B904 (raise-without-from-inside-except) violations.

except httpx.HTTPStatusError as e:
    raise LLMServiceError(...)          # ← original HTTP error lost
except httpx.TimeoutException:
    raise LLMServiceError("... timeout") # ← no `as e`, no chain
except Exception as e:
    raise LLMServiceError(...)          # ← `e` captured but not chained

Why it matters

The wrappers flatten every failure into a generic message. When something goes wrong talking to LM Studio or xAI (TLS error, connection reset, malformed JSON), the underlying httpx exception — the part that actually tells you what broke — is thrown away. Chaining preserves it as __cause__, so the real cause shows up in tracebacks and debugging:

GrokServiceError: Grok error: ...
The above exception was the direct cause of the following exception:
httpx.ConnectError: [Errno 111] Connection refused

The change

Add from e to all six handlers and bind the two TimeoutException blocks with as e. Behaviour-preserving: exception types, messages, and details are unchanged, so any caller catching LLMServiceError / GrokServiceError is unaffected — only __cause__ is now populated.

Verification

ruff check llm/client.py --select B904   →  0 findings (was 6)
python -c "import ast; ast.parse(open('llm/client.py').read())"  →  parses OK

🤖 Generated with Claude Code

https://claude.ai/code/session_01LvLWMML8cpBq2q81kL1ByJ

---

Generated by Claude Code