feat: apply mureo's safety layer (audit / strategy / rollback / throttle) to plugin tools (BYOD excluded)

[hyoshi]

Summary

mureo's plugin layer (Issue #89: MCPToolProvider → mcp__mureo__* tools) exposes a third-party provider's operations as MCP tools, but those tools bypass mureo's value/safety layer. A plugin (e.g. a private ad-network adapter) currently gets the integration boundary + fault isolation only — not audit/action-log, strategy gating, rollback tracking, or throttle. This issue tracks making plugin tools participate in mureo's cross-cutting safety guarantees.

Out of scope (explicit, per maintainer): BYOD. Plugins are not required to support BYOD. Everything else (security/audit/strategy/rollback/throttle, and workflow integration) is in scope.

Current behavior (verified in code)

• mureo/mcp/server.py handle_call_tool routes plugin tools straight to _PLUGIN_DISPATCH[name].handle_mcp_tool(name, arguments). There is no central middleware; built-in platforms implement audit/strategy/rollback/throttle per-handler (_handlers_* + mureo/throttle.py Throttler wired into each platform client; _handlers_mureo_context.append_action_log / handle_strategy_get; _handlers_rollback / tools_rollback). The plugin path touches none of it.
• docs/plugin-authoring.md §10 frames input validation, secrets hygiene, bounded calls, etc. as plugin-side responsibilities — mureo does not enforce them for plugin tools.
• Net: a write-capable plugin's mutations are not in mureo's audit log, not reversible via mureo rollback, not strategy-gated, not throttled unless the plugin hand-calls mureo's mureo_state_* tools.

In scope

1. Audit / action log: every plugin tool call (esp. mutations) is recorded in mureo's action_log (tool name, args [secret-masked], result/outcome, source distribution) — automatically, not opt-in.
2. Strategy gating: plugin mutations consult STRATEGY.md/STATE.json the way built-in mutations do (or are flagged when they cannot be evaluated).
3. Rollback: plugin mutations register a rollback plan where reversible; surface in rollback_plan_get. Requires the plugin to declare reversal semantics (ABI addition) — default to "non-reversible, audit-only" when undeclared (safe).
4. Throttle: a default Throttler is applied at the plugin dispatch boundary; overridable via a plugin-declared rate hint.
5. Security gating: enforce/centralize what mureo can (e.g. secret-masking in the audit record, argument-size limits) rather than relying solely on plugin diligence; keep the rest documented as plugin responsibility.
6. Workflow integration (noted, larger): letting daily-check / rescue / etc. orchestrate plugin platforms is a separate, bigger design (skills are hand-written per platform — same class as Issue feat: first-class Amazon Ads support (official Amazon Ads MCP integration) #113 Amazon). Track here as a later phase, not the first deliverable.

Constraints (must not regress)

• Fault isolation: collection-time isolation (Issue Introduce plugin architecture for third-party advertising platform providers #89) must be preserved; the dispatch path is currently NOT fault-isolated — wrapping it with audit/rollback must not turn a plugin exception into a server crash, and must not swallow errors silently.
• ABI stability: any new MCPToolProvider capability (mutation flag, reversal hint, rate hint) must be opt-in & backward compatible (existing plugins keep working with safe defaults). Update docs/ABI-stability.md.
• No double-application for built-ins (they already do this per-handler; only the plugin dispatch path gets the new middleware).
• Performance: audit/throttle wrapper must be cheap on the read path.

Proposed phased plan

• Phase 1 (smallest, highest value, no ABI break): central middleware around the plugin dispatch branch in handle_call_tool — automatic action-log append for every plugin tool call (name, masked args, ok/err, source_distribution) + a conservative default throttle. Safe defaults; no plugin changes required. TDD.
• Phase 2: opt-in MCPToolProvider metadata — mutating: bool, optional rollback/reversal descriptor, optional rate hint — consumed by the middleware for strategy gating + rollback-plan registration; undeclared ⇒ treated as non-reversible mutation, audit-only. ABI doc + plugin-authoring doc updates.
• Phase 3 (separate/optional): workflow-skill orchestration of plugin platforms (provider-aware skill extension) — large; may split to its own issue.

Acceptance criteria (Phase 1)

• Every plugin tool invocation produces an action_log entry (secrets masked) without the plugin opting in.
• Default throttle applied to plugin dispatch; built-ins unaffected.
• Plugin exception at call time still surfaces as a clean tool error (no server crash, no silent swallow); fault-isolation parity documented.
• Existing plugins (no metadata) keep working byte-identically aside from now being audited/throttled.
• Tests + CI green; docs/plugin-authoring.md / mcp-server.md updated to state what mureo now enforces vs plugin responsibility.

Priority: develop this BEFORE Issue #113 (Amazon), per maintainer. Issue #113 (Amazon) remains Phase-0-blocked separately.