feat/issue65 llm providers

[ar7casper]

• feat(openant-core,openant-cli): pluggable LLM adapter framework + multi-provider support (issue [feat] Enable OpenAnt to work with non-Claude LLMs (Qwen, Kimi, local models, etc.) #65)
• docs: README + CHANGELOG for multi-provider work

[gadievron]

Reviewed the adapter framework in depth (multiple passes, plus a head-to-head against another project that did this same native-SDK migration). Architecture is solid — clean Protocol, PhaseBinding wiring, backward-compat preserved, credentials baseline sound (0600, masking, traversal-blocked, the Go side redacts key= from probe URLs). Good call using native SDKs rather than a gateway lib. Static analysis (semgrep + CodeQL, security + quality, both languages) is clean, so the items below are behavioral asymmetries between the three adapters, not anything a scanner flags.

In the new adapter framework — worth fixing:

• HIGH — Anthropic has no empty-content guard. A well-formed refusal/empty completion yields content=(), stop_reason=end_turn, simple_text() -> ''. openai.py:365 (empty choices) and google.py:346 (empty candidates) both raise LLMResponseError; anthropic.py:305-356 doesn't. Because the verify phase then defaults to agreeing with Stage 1 on empty text, a refusal can silently become a clean security verdict (false negative). Suggest mirroring the OpenAI/Google guard in AnthropicAdapter._response_to_unified.
• MED — refusal / content-filter is normalized to end_turn (warn-only) in all three adapters. For a SAST tool a masked refusal is a masked false-negative. A typed LLMRefusalError raised on refusal finish reasons keeps it from reading as a normal short answer (distinct from the empty-guard above — this fires on a populated refusal).
• MED — Google max_retries is silently dropped (google.py:158 _ = max_retries). The docstring says the SDK doesn't expose retries, but HttpOptions.retry_options=HttpRetryOptions(attempts=...) does (and you already build HttpOptions at :154). Anthropic/OpenAI forward it; Google should too — and the docstring is misleading.
• MODERATE — the setup wizard echoes the pasted API key. setup.go:412 -> readLine (bufio.ReadString) prints input as typed; there's no term.ReadPassword in cmd/ (charmbracelet/x/term is already an indirect dep). set-api-key <key> also takes the key as an argv (shell history / ps). A no-echo read closes both.
• LOW — Anthropic reads response.usage unguarded (anthropic.py:329, outside the try) -> a usage-less response raises an unmapped AttributeError; OpenAI :422 / Google :360 use getattr(..., None).
• LOW — error mapping passes raw exception strings through. All three adapters do raise LLMError(str(exc)) with no redaction layer; provider 400/401 bodies can echo request context. Worth scrubbing secrets before these propagate to logs/reports.

Several of these are the same shape — handled in two adapters, missed in the third (Anthropic is the odd one out on the empty-guard and on usage; Google on retries) — so they're cheap to fix together.

Two pre-existing issues this PR's completion path now feeds (flagging because they're high-impact, not asking you to redesign here): the verify phase defaults to "agree with Stage 1" on every degenerate path — incomplete/empty completion (finding_verifier.py:380, where the empty-completion case lands), no tool calls (:448), max-iterations reached (:464), and even a finish call that omits the agree field (:925, get("agree", True)). For a security verifier that biases systematically toward false negatives, so the empty-completion case above is one of four inputs that silently rubber-stamp Stage 1. Separately, untrusted analyzed source is interpolated into the verifier prompt inside a bare triple-backtick fence (verification_prompts.py:106-125) with no escaping, so a crafted source file can break out of the fence and steer the verdict. Both are worth a fix independent of this PR.

Happy to share repros for any of these.