docs: fix 3 more unverified claims (4-thread->8, 12 locks->11, _search_mcp real)

Re-audit after reading the actual full file contents:

1. guide_app_controller.md (the __init__ walkthrough):
   - '4-thread ThreadPoolExecutor' -> '8-thread' per IO_POOL_MAX_WORKERS = 8
     in src/io_pool.py:20 (bumped from 4 in commit 4a338486; the io_pool.py
     module docstring is also stale and says '4 worker threads' - flagged
     for a separate fix).
   - '12 locks' -> '11 locks + 5 non-lock state fields' (re-counted the
     threading.Lock() and the _rag_sync_*/_project_switch_* fields).

2. guide_app_controller.md (the closing line):
   - '12 locks' -> removed; explained the 434-line __init__ body
     composition (locks + state fields + settable_fields + gui_task_handlers).

3. guide_rag.md (Future Work section):
   - 'The _search_mcp method is a placeholder for this' -> WRONG.
     _search_mcp (src/rag_engine.py:322) IS a real implementation that
     calls mcp_client.async_dispatch when vector_store.provider == 'mcp'.
     Rewrote the future-work item to describe the actual mechanism.

4. docs/reports/docs_sync_test_era_20260610.md (the closing report):
   - Same 4-thread->8 and 12-locks->11 corrections propagated.

The structural facts (WorkspaceProfile/RAGConfig/VectorStoreConfig field
lists, method existence, _init_actions/_load_active_project line
numbers, _LiveGuiHandle existence, etc.) were all correct. The
counting/threading-pool claims I cited from memory were the ones
that needed re-verification.

docs/guide_rag.md

@@ -434,7 +434,7 @@ For unit tests that don't need real embedding models, the `BaseEmbeddingProvider
 
 ## Future Work
 
-- **External RAG Bridge** — Connect to remote vector databases (e.g., a managed Pinecone or Weaviate) via MCP. The `_search_mcp` method is a placeholder for this.
+- **External RAG Bridge** — Connect to remote vector databases (e.g., a managed Pinecone or Weaviate) via MCP. The `_search_mcp` method (`src/rag_engine.py:322`) IS a real implementation: when `RAGConfig.vector_store.provider == "mcp"`, `RAGEngine.search()` dispatches to `_search_mcp()` which calls `mcp_client.async_dispatch("rag_search", {"query": ..., "top_k": ...})`. The MCP-bridge config (`mcp_server`, `mcp_tool`) lives on `VectorStoreConfig`. The bridge wires up the rest of the RAG pipeline to a remote vector store; no per-vendor `_init_vector_store` branch is needed because the MCP server owns that.
 - **Hybrid Search** — Combine dense (vector) retrieval with sparse (BM25) retrieval for better recall on code keywords.
 - **Re-ranking** — Apply a cross-encoder reranker to the top-k results before injection to improve precision.
 - **Caching** — Cache query results in memory to avoid re-embedding for repeated questions.