feat(mcp): converge plugin-bridge & multiplexer governance — one policy model + contextual (channel/mode/session) scoping

[Nibbler1250]

Context

Governance over MCP tool calls exists on both dispatch paths today, but the two grew separately:

Plugin-tool bridge (src/plugins/mcp-bridge.ts)

• Append-only audit, HMAC call signing (signCall/verifyCall), pluginId validation + fqn namespacing.
• feat(plugins): MCP tool policy layer — scoped permissions + deny-by-default + per-tool kill switch on the plugin-tool bridge #230 proposes adding scoped permissions / deny-by-default / per-tool kill switch here.

MCP multiplexer (src/plugins/mcp-multiplexer/)

• Already has per-server enabled (kill switch) and allowedTools allow-list (~/.config/claudeclaw/mcp-proxy.json).
• AuditPolicy (settings.mcp.audit): enforce (fail-closed — "no log → no action", synchronous intent gate) vs best-effort (default).
• Unified mcp.tool_call audit chain (src/observability/tool-call.ts), per-PTY identity + revocation, rate-limit, cost metrics (mcp-multiplexer: cost-tracking metrics on dispatch path #68), idempotent-tool cache (mcp-multiplexer: response caching for idempotent tools #69).

Observation

The multiplexer already establishes a fairly mature policy + audit vocabulary; the bridge is the less-governed of the two paths. If #230 and the multiplexer evolve independently we risk:

1. Divergent schemas — two different config shapes for the same conceptual control (enable/allow/deny a tool).
2. Two audit streams instead of one combined "what can Claude call, where, and was it allowed?" surface.

Proposal (for discussion)

Converge on one policy model + one audit chain across both paths:

• The bridge policy (feat(plugins): MCP tool policy layer — scoped permissions + deny-by-default + per-tool kill switch on the plugin-tool bridge #230) reuses the multiplexer's vocabulary (enabled, allowedTools, AuditPolicy enforce/best-effort) rather than introducing a parallel model.
• The capability genuinely missing on both paths today: contextual scoping — per-channel / per-mode / per-session. Current allow-lists are per-server / per-tool, not contextual. Added once, in the shared model.
• Both paths emit policy decisions through the existing mcp.tool_call chain, so audit stays single-stream.

@TerrysPOV — keen on your input before any SPEC

Your repo, your call — flagging the design question before either of us builds:

1. One unified policy model across bridge + multiplexer, or keep them separate and just align vocabulary?
2. Is contextual (channel / mode / session) scoping in scope, or is per-server / per-tool sufficient for the regulated posture you're targeting?
3. Where should the shared policy schema live (settings block, plugin manifest, both)?

Refs #230, #31, #70.