docs(mcp): record that write_file/virtual-FS tools are intentionally unused

Answering "is there Studio Pro MCP functionality we don't support?": the model-
authoring surface is fully wired, and the unused PED tools are all redundant or
out of scope — document/folder lookup is covered by the local .mpr reader, and the
virtual-file tools (write_file/read_file/glob) exist for Maia, the in-IDE agent
with no disk access. Coding agents like Claude Code / mxcli have direct filesystem
access to the project, so source files (Java/JS/CSS) are edited on disk directly;
the virtual FS would be pure overhead. Update the write_file matrix note from
"potential alternative" to "intentionally not used — not a capability gap" so it
isn't later mistaken for missing functionality. No code change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: ako

docs/03-development/PED_MCP_CAPABILITIES.md

@@ -66,7 +66,7 @@ blank = absent, `—` = n/a). `cmd/mcpprobe -method tools/list` is the source.
 | `read_skill` | ✓ | Load a Maia skill. (Agent helper; not used.) |
 | `glob` | ✓ | List files in a virtual file domain. (Agent helper; not used.) |
 | `read_file` | ✓ | Read a file in a virtual file domain. (Agent helper; not used.) |
-| `write_file` | ✓ | Write Java/JS/CSS in a virtual file domain. (Potential alt to mounted-fs writes.) |
+| `write_file` | ✓ | Write Java/JS/CSS in a virtual file domain. **Intentionally not used** — these exist for Maia (the in-IDE agent with no disk access). Claude Code / mxcli run with direct filesystem access to the project, so source files are edited on disk directly; routing through the virtual FS would be pure overhead. Not a capability gap. |
 
 `initialize` instructs clients to first read the resource
 `mendix://studio-pro/system-prompt` (the Maia system prompt + PED contract).