feat(catalog): cover Windows guest-mutating tools in the starter list

The catalog is opt-in: an unlisted tool passes through unguarded. The
shipped starter list was ssh/exec and ansible/run_playbook, both Linux
shaped, so an agent changing a protected Windows guest over WinRM or
PowerShell was never guarded at all. That does not fail loudly, it
simply never inserts a checkpoint.

Adds winrm/run_command, winrm/run_ps, powershell/invoke_command and
smb/write_file. The smb entry is there because a file written into a
share changes the guest without any shell being involved.

Test asserts the example config covers both platforms and that every
entry names a vm_arg, since without one the guard cannot resolve a VM.

Still illustrative, not exhaustive: tool names vary per MCP server, so
users add their own with zerto_add_mutating_tool. That reactive model is
the real weakness here and is worth revisiting separately.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

config.example.json

@@ -17,6 +17,30 @@
       "tool": "run_playbook",
       "vm_arg": "limit",
       "notes": "Playbook target host/group. Resolve to a single VM before guard."
+    },
+    {
+      "server": "winrm",
+      "tool": "run_command",
+      "vm_arg": "host",
+      "notes": "Windows remote shell over WinRM. vm_arg is the hostname."
+    },
+    {
+      "server": "winrm",
+      "tool": "run_ps",
+      "vm_arg": "host",
+      "notes": "PowerShell over WinRM. Same blast radius as run_command."
+    },
+    {
+      "server": "powershell",
+      "tool": "invoke_command",
+      "vm_arg": "computer_name",
+      "notes": "Invoke-Command against a remote Windows guest."
+    },
+    {
+      "server": "smb",
+      "tool": "write_file",
+      "vm_arg": "host",
+      "notes": "Writes a file into a Windows share. Changes the guest without a shell."
     }
   ]
 }