docs(mcp): fix Ollama config example to use nested provider schema

[xiaoyaner0201]

Fixes #1556.

Problem

The "Using Ollama for Local LLM" example in mcp_server/README.md documents a flat provider schema that the current config models no longer accept. Copying it verbatim fails to construct either client:

LLM create FAILED: ValueError: OpenAI provider configuration not found      (factories.py:140)
EMB create FAILED: ValueError: Unsupported Embedder provider: sentence_transformers  (factories.py:410)

Two independent defects in the same block:

1. llm.api_base / llm.api_key are not fields on LLMConfig. mcp_server/src/config/schema.py requires the endpoint under providers.openai.api_url. With the documented shape, config.providers.openai stays None, so LLMClientFactory.create raises — and is_non_openai_provider() never sees the Ollama URL, so even if construction succeeded the routing would be wrong.
2. embedder.provider: sentence_transformers is not a supported provider. EmbedderProvidersConfig supports openai | azure_openai | gemini | voyage; sentence_transformers falls to case _ and raises. Ollama serves embeddings on the same OpenAI-compatible endpoint, so openai is the correct provider here.

Change

Docs-only rewrite of the Ollama YAML block to the nested providers: schema already used elsewhere in this README and in mcp_server/config/config.yaml, plus a regression test.

The test (mcp_server/tests/test_readme_config_examples.py) extracts the YAML from README.md at runtime rather than copying it — so it is a real drift fence: if the section reverts to the flat shape, the test goes RED again. It asserts the documented endpoint lands on providers.openai.api_url, that LLMClientFactory.create actually returns an OpenAIGenericClient (Chat Completions path), that EmbedderFactory.create constructs, and that every embedder provider: appearing in the README is in the factory's supported set.

No schema.py / factories.py changes. No new provider added. No other README section touched.

Test plan

Base: 71a719be482294dd4bbfc5cef557a3a6a500c134. No network, no API key, no database required.

cd mcp_server
GRAPHITI_TELEMETRY_ENABLED=false uv run pytest tests/test_readme_config_examples.py -v
# RED on base: 4 of 5 fail with exactly the two ValueErrors above
# GREEN with this change: 5 passed

GRAPHITI_TELEMETRY_ENABLED=false uv run pytest \
  tests/test_readme_config_examples.py tests/test_configuration.py tests/test_factories.py -q
# 36 passed

Related regressions are clean, so no baseline attribution was needed. ruff check and ruff format --check on the new test file are clean.

Independent adversarial probes were run on throwaway copies of the tree: reverting the README block, renaming the section heading, and swapping api_url to the official OpenAI endpoint each make the test fail as intended — confirming the fence bites rather than passing vacuously.

Refresh onto current main

Branch refreshed via merge of upstream/main (2645dee, the only upstream delta being a CLA record in signatures/version1/cla.json) at head 864d41ee8a677f42f2d0958c3170c28882420fa3. The two-file candidate patch is byte-identical before/after the refresh (patch SHA-256 b4c26640b75a7a72b21be8570b7a7280114a28ccc9366806ad7b367d8b1186d5). Post-refresh re-verification: 36 focused tests pass, ruff check / ruff format --check clean, and an independent read-only review of the exact tree found zero unresolved findings.

CI note

The triage check failure on this PR is a known infrastructure problem in the anthropics/claude-code-action runner when triaging fork PRs, not a defect in this change — the job log shows Internal error: directory mismatch for directory ".../claude-code-action/.../tsconfig.json", fd 4. You don't need to do anything, but this indicates a bug. (https://github.com/getzep/graphiti/actions/runs/30499248316/job/90735021052). All candidate-owned checks (ruff, CLA, Socket, check-fork) are green.

Notes

Docs + test only; no runtime behavior change.