feat: add mcp_prompts_resources plugin

[venkat-raman17]

Summary

Code Puppy consumes MCP tools only. MCPToolset already implements list_prompts, get_prompt, list_resources and read_resource — so prompts and resources on a configured MCP server are unreachable purely for want of wiring. This plugin surfaces them.

Motivation: running a platform-curated stdio MCP server, the tools work but the prompts and docs the same server publishes are invisible.

Adds four agent tools: list_mcp_prompts, get_mcp_prompt, list_mcp_resources, read_mcp_resource.

list_mcp_prompts   -> platform:playbook(topic) - Curated playbook.
get_mcp_prompt     -> Run the playbook for incident
list_mcp_resources -> platform docs://runbook - runbook
read_mcp_resource  -> internal runbook body

Notes

• Agent tools, not slash commands. Tool calls run inside the agent's async context, so the async MCP calls need no sync/async bridge. A sync command handler runs on the event loop thread and would deadlock if it blocked for a result — and MCPCommandHandler._commands is a hardcoded dict in core, so /mcp <sub> isn't extensible from a plugin anyway.
• Only running servers are queried, and only when they advertise the matching capability. Stopped, disabled or quarantined servers are skipped rather than raising — MCPToolset.capabilities raises AttributeError until the toolset is entered, which the capability check absorbs.
• Errors are per server. One bad server degrades its own line instead of blanking the listing. A failed get_prompt keeps its message, so a missing required argument reports as such rather than masquerading as "prompt not found".
• get_mcp_prompt accepts server:prompt or a bare prompt name.
• No core changes required — this uses only existing public APIs (get_mcp_manager, unwrap_toolset, toolset_is_running, and the register_tools / register_agent_tools phases).

Testing

16 new tests, all passing. Suite: 2162 passed.

The 18 remaining failures are pre-existing and unrelated (oauth token-storage permission bits, symlink rejection, statusline, spill, computer_use policy) — all Windows-environment limitations around file permissions and symlink privileges, in plugins this PR doesn't touch.

Also verified end to end against a live stdio MCP server, and through the real plugin loader — the four tools appear in both on_register_tools() and on_register_agent_tools().

Sampling and elicitation are deliberately out of scope: those are server-initiated requests that need a consent and UI surface, unlike these read calls.

🤖 Generated with Claude Code

[venkat-raman17]

@mpfaffenberger , Can you please review the PR?