docs: fix mcp runner redaction mechanism, note create_workflow's scope and fan-out checks

docs/vantage/mcp.md

@@ -158,6 +158,12 @@ create is armed:
   `secret_refs` argument, because a script an agent wrote is not something
   you want run with credentials attached before a person has read it.
 
+`create_workflow` applies the same two checks `run_workflow` applies before
+a run: it refuses to save a workflow whose targets are not entirely inside
+the token's tag scope, and it refuses (absent `confirm:true`) to save one
+whose targets exceed the 25-server fan-out limit. A workflow this token
+could not later run is never created in the first place.
+
 Steps an agent creates are marked with a `source` of `mcp`, which the
 Vantage UI uses to badge them, so a human reviewing the step library can
 tell at a glance which scripts came from an agent rather than a person.
@@ -195,10 +201,16 @@ This is the section to read before turning the feature on.
   workflow or monitor a person defined.
 
 A monitor whose runner server sits outside a token's scope is not hidden
-from that token — it still appears in `list_monitors` — but the runner
-field is left out, the same redaction the REST API already applies. A
-workflow's target list is filtered the same way: servers outside the
-token's scope are dropped from what `get_workflow` reports, and a
+from that token — it still appears in `list_monitors`. The REST API reaches
+that outcome by redacting: it replaces the runner with a
+`RunnerRestricted` placeholder when the runner falls outside the caller's
+visible servers. The MCP tools reach the same outcome a different way —
+`list_monitors` and `get_monitor_status` project a monitor onto a summary
+that never carries a runner field for any caller, restricted or not, so
+there is nothing there to redact in the first place. Two mechanisms, chosen
+so the two surfaces cannot end up disagreeing about what a restricted token
+learns. A workflow's target list is filtered more directly: servers outside
+the token's scope are dropped from what `get_workflow` reports, and a
 `targets_restricted` flag says that some were held back, without saying how
 many.