AI reviewer picks OpenAI over Anthropic by key presence, with no logging or explicit config

## Summary `app/ai/reviewer.py::AIReviewer._get_client` chooses between OpenAI and Anthropic purely based on which API key happens to be set, with OpenAI taking silent priority. There's no explicit config option to pick a provider, and no log line explaining which one was selected. ## Where `app/ai/reviewer.py`: ```python def _get_client(self): if self._client is None: if settings.openai_api_key: import openai self._client = openai.AsyncOpenAI( api_key=settings.openai_api_key, base_url=settings.openai_base_url, ) self._client_type = "openai" elif settings.anthropic_api_key: import anthropic self._client = anthropic.AsyncAnthropic( api_key=settings.anthropic_api_key ) self._client_type = "anthropic" ... ``` ## Problem - If an operator has both `OPENAI_API_KEY` and `ANTHROPIC_API_KEY` set — for example, leftover from testing one provider and switching to another, or because they use OpenAI for something else entirely in the same environment — the bot silently uses OpenAI, even if the intent was to use Anthropic (the project's own README frames AI review as "via the Anthropic SDK"). - There is no log output at startup or at review time stating which provider/model was actually used. Debugging "why did the AI review use the wrong model/tone" requires reading source code, not logs. - This is implicit, order-dependent config: whichever key exists wins, rather than an operator making a deliberate choice. ## Suggested fix - Add an explicit `AI_REVIEW_PROVIDER` (or similar) setting (`"openai" | "anthropic" | "auto"`), defaulting to `"auto"` for backward compatibility with today's key-presence behavior. - Log the resolved provider and model on first client creation, e.g. `log.info("AI reviewer using provider=%s model=%s", self._client_type, cfg.model)`. - Consider warning at startup if both keys are set and no explicit provider is configured, so the ambiguity is visible instead of silent. ## Note Open PR #59 ("feat: pluggable AI review backends, including local open-weight models") may already touch this area — worth checking whether it introduces explicit provider selection before starting work here, to avoid overlapping changes. ## Severity Low — no functional bug, purely an operator-experience / debuggability gap.