Wire plugin tools end-to-end: LLM visibility, execution dispatch, config, hooks, and channel messaging #32

Summary

The OpenClaw Unicity plugin loads and discovers tools through our Node.js MCP bridge, but six critical pathways are broken:

1. Plugin tools never reach the LLM's tool list
2. Plugin tool execution routes through ServerManager which doesn't know about plugins
3. Plugin config never reaches the bridge subprocess
4. Hook forwarding (before_agent_start) is dead code
5. Inbound channel messages have no Rust-side handler
6. Outbound channel message routing has no mechanism

This issue tracks the minimal changes needed to make the Unicity plugin (and any future MCP-backed plugin) fully functional end-to-end.

Sub-Issues (4 PRs)

Phase A (parallel):
  ├── #33 Items 1+2 (tool wiring)
  └── #34 Item 3 (config passing)

Phase B (after #33):
  └── #35 Item 4 (hook forwarding)

Phase C (after all above):
  └── #36 Items 5+6 (channel messaging)

Design Decision: PluginRegistry on AgentRuntime vs ServerManager Registration

Considered: Registering plugin Peer<RoleClient> handles directly into ServerManager so plugin tools flow through the existing MCP tool list and dispatch path automatically.

Rejected because:

• ToolCall::parse_name() uses split_once(':'). Tool name plugin:my-plugin:echo splits as server=plugin, tool=my-plugin:echo — wrong server lookup. Fixing this requires either dropping the plugin: prefix (name collision risk with MCP servers) or custom parse logic.
• Lifecycle dual-ownership: both ServerManager::stop() and McpPlugin::unload() would try to close the same peer session.
• ServerManager requires ServerConfig for each entry (restart policy, command, args) — plugins have their own lifecycle via Plugin::load()/unload().

Chosen approach: Add PluginRegistry as an optional field on AgentRuntime. Explicit, avoids naming conflicts, clean separation of plugin vs MCP server lifecycle.

Scope

• ~6 files modified, 0-1 new files
• Core changes in runtime.rs and mcp_plugin.rs
• Bridge changes: 1-2 notification handlers in astrid_bridge.mjs
• New dependency: astrid-plugins added to astrid-runtime/Cargo.toml
• No new crates

Safety & Failure Modes

Verification

1. Unit tests: Extend PluginRegistry tests to cover tool list merging; add AgentRuntime test with mock plugin
2. Integration test: Load Unicity plugin via gateway, verify:
   • Plugin tools appear in list_tools RPC response
   • Calling a plugin tool returns a result (not "server not found")
   • Plugin config is non-empty in bridge (add debug log)
   • before_agent_start hook fires and context is prepended
3. End-to-end: Send a message through CLI → agent → Unicity channel → verify round-trip
4. Run: cargo test --workspace -- --quiet to ensure no regressions