feat(mcp): wire entry-point provider plugins into the MCP server

[hyoshi]

Summary

Adds the missing MCP boundary so a third-party provider discovered via the
mureo.providers entry-point group can surface its operations as
mcp__mureo__* tools. Until now the registry (P1-07) discovered providers and
the skill matcher (P1-08) gated them by capability, but a discovered provider
had no way to be exposed as MCP tools — mureo/mcp/server.py built a static
tool list and never called registry.discover().

Single commit off main (93282d5). Not for self-merge — opening for review.

Design decision (the architecture call)

Two designs were considered:

• A — auto-generate MCP tools from the domain Protocol (plugin authors write
  zero MCP code; matches the long-term vision but large, and cannot expose
  platform-specific operations outside the Protocol).
• B (this PR) — an opt-in secondary Protocol MCPToolProvider
  (mcp_tools() + async handle_mcp_tool()), mirroring the shape every built-in
  platform module already uses (TOOLS + async handle_tool).

B was chosen as the pragmatic, industry-standard plugin pattern (pytest /
Flask / setuptools style). It is strictly more flexible for platform-specific
APIs and does not preclude A as a later evolution. BaseProvider's own
docstring mandates extending via secondary Protocols rather than expanding it —
B follows that.

What changed

• mureo/mcp/tool_provider.py (new): MCPToolProvider runtime-checkable
  Protocol + collect_plugin_tools() — entry-point discovery, no-arg construct,
  isinstance gate, async-handler gate, per-plugin fault isolation (incl.
  SystemExit; KeyboardInterrupt re-raised), built-ins win on name collision,
  first-wins on plugin-vs-plugin collision.
• mureo/mcp/server.py: purely additive — reserved_names = union of
  all built-in tool-name frozensets, _ALL_TOOLS.extend(plugin tools), one
  dispatch branch after all built-in families. No plugins means byte-identical
  behaviour to before.

Safety / regression

• 938 tests pass across the mcp/provider/registry/skill/adapter blast
  radius — the additive guarantee is locked by a dedicated
  test_no_plugins_is_additive_no_op.
• A plugin cannot shadow a core tool (reserved-set drop + built-in dispatch
  precedence; covered end-to-end).
• A broken/malicious plugin cannot crash the server or starve siblings
  (construct / mcp_tools() / total-discovery faults each isolated).
• ruff clean; mypy clean for the two changed source files (a pre-existing
  unrelated search_console/client.py:69 unused-ignore is out of scope).
• python-reviewer: APPROVE, 0 CRITICAL/HIGH; flagged MEDIUM/LOW
  (BaseException isolation, end-to-end shadow test, first-wins identity,
  sync-handler rejection) all addressed in this commit with regression tests.

Test plan

• tests/test_mcp_tool_provider.py — discovery, collision, dedupe,
  isolation (incl. SystemExit), sync-handler rejection
• tests/test_mcp_server_plugin_wiring.py — list/dispatch, built-ins
  intact, unknown-tool raises, real-core-tool shadow rejected, additive no-op
• 938-test blast-radius regression, ruff, mypy
• CI (gh pr checks) — pending on this PR

Companion (private, separate repo)

logly/mureo-logly-bridge already implements the MCPToolProvider surface
(commit 17dbf6c). It needs no further change once this lands — it was built
structurally against this contract. No OSS reference to it (verified by
git grep).

🤖 Generated with Claude Code