fix(mcp): gate ChatGPT compatibility tools by clientInfo

[phernandez]

Why

ChatGPT advertises itself as openai-mcp in clientInfo, and the OpenAI MCP directory expects the compatibility search and fetch tools for deep research/company knowledge flows. Other MCP clients can use the native Basic Memory tools, so the ChatGPT-only shims should not run for Codex, Claude, or generic clients.

What Changed

• Capture sanitized MCP initialize.clientInfo in FastMCP session state.
• Gate the ChatGPT compatibility search and fetch tools on openai-mcp / openai-mcp/....
• Return structured unsupported-client payloads that point other clients to search_notes and read_note.
• Update unit and integration tests so ChatGPT-flow tests identify as openai-mcp, with default-client rejection coverage.

Implementation Details

The gate is deliberately based on MCP session state from initialize, not on a separate endpoint or auth route. The client match accepts the exact dashboard labels we have seen (openai-mcp and openai-mcp/1.0.0) in either name or title; missing or non-OpenAI labels fail closed.

Testing

• uv run pytest tests/mcp/test_client_info.py tests/mcp/tools/test_chatgpt_tools.py test-int/mcp/test_chatgpt_tools_integration.py -q passed.
• just fast-check passed lint, format, typecheck, and the selected MCP tests; it failed only on test-int/semantic/test_semantic_quality.py::test_semantic_quality[asyncio-postgres-openai] because the live OpenAI embeddings request returned 429 insufficient_quota.

Risks / Follow-ups

The cloud MCP telemetry middleware still needs to preserve recovered clientInfo across stateless HTTP tool calls; that is handled in the paired Basic Memory Cloud PR.