docs: add Key interfaces section to adapters README (#94 review)

src/ README audit gate looks for a `## Key interfaces` (or `## Public
surface`) anchor — the existing README had purpose / table /
extension recipe / layering rationale, but no exported-names section.

Adds a `## Key interfaces` section listing the two exported names:

  - AzureOpenAIClient — the LLMClient implementation with notes on
    complete() vs complete_json() and the discarded `model` arg
    (Azure dispatches by deployment, not model).
  - AzureOpenAIConfigError — the construction-time error type,
    noting that it batches every missing env var into a single
    message instead of failing-and-retrying.

Both already documented in the adapter docstrings; this section
hoists them to the README anchor the audit gate enforces.

Refs #94

Author: constk

src/eval/adapters/README.md

@@ -2,6 +2,13 @@
 
 Concrete `LLMClient` adapters for the eval harness. The judge in [`src/eval/judge.py`](../judge.py) calls an `LLMClient` Protocol — never a vendor SDK directly. Each adapter in this package implements that Protocol for one provider, so the eval core stays vendor-neutral and a downstream consumer can swap providers by changing one wiring line in their test fixture.
 
+## Key interfaces
+
+Exported from this package:
+
+- **`AzureOpenAIClient`** — implements `src.eval.judge.LLMClient`. Construct from env via `AzureOpenAIClient()`; call `complete(prompt)` for runner `answer_fn` use, `complete_json(*, model, prompt)` for judge use. The `model` argument on `complete_json` is accepted for Protocol conformance and discarded — Azure addresses by deployment name (set at construction time, read from `AZURE_OPENAI_DEPLOYMENT`).
+- **`AzureOpenAIConfigError`** — raised at construction when required env is missing or the optional `openai` extra is not installed. Subclass of `RuntimeError`. The error message names every missing env var in one go so the caller doesn't have to fix-and-retry.
+
 ## Why this layer exists
 
 Without the Protocol seam, swapping LLM providers would mean touching the eval core. With it, vendor lock-in is confined to one file per provider. The layer demonstrates that the harness's "provider-agnostic" claim is structural, not aspirational: the eval core has zero imports of any vendor SDK.