fix(frame): 未知工具错误码 -32601 改为 -32602，符合 MCP 规范

MCP 规范《Tools / Error Handling》把「未知工具」归为**协议错误**，
示例即为 {"code": -32602, "message": "Unknown tool: invalid_tool_name"}。
基座原先回 -32601（Method not found），语义偏 JSON-RPC 方法层。

- mcp_configParser.cpp: mcp_Tools::Call 改 -32601 → -32602，
  消息改为 "Unknown tool: <name>"。
- 无需改 mcp_server.cpp 的 HandleToolsCall：其协议错误白名单
  {-32700,-32600,-32601,-32602} 已含 -32602，分类逻辑不变。
- 同步更新 verify_mcp_frame.py 与 verify_stdio_bridge.py 的断言
  （未知「方法」仍是 -32601，语义正确，不动）。

验证（重建基座 + 重启 CAD 后实测）：
- 直连 TCP：{"error":{"code":-32602,"message":"Unknown tool: __no_such_tool__"}}
- verify_mcp_frame.py 4/4 PASS；verify_stdio_bridge.py 24/24 PASS
- 回归：verify_annotate.py 9/9、dwg_review --check 正常
- MCP Inspector 冒烟：tools/list 26 个工具、tools/call get_drawing_info 正常

ai.memory/project_stdio_bridge.md

@@ -24,7 +24,7 @@ type: project
 | 生命周期 | **没有** `initialize` / `initialized` / `ping` → **必须由桥合成** |
 | 通知 | 无 `id` 即不回包 |
 | `tools/list` | 26 个工具，`name`/`description`/`inputSchema(type=object)` 已是标准 MCP 形状 → **可原样转发** |
-| 未知工具 | 回**顶层** `error:-32601`（不是 `result.isError`）→ 桥忠实透传 |
+| 未知工具 | 回**顶层** `error:-32602`（`"Unknown tool: <name>"`）→ 桥忠实透传 |
 
 ## 关键设计决策
 
@@ -37,9 +37,12 @@ type: project
 3. **stdout 纯净性**：只用 `sys.stdout.buffer.write(... + b"\n")` + `flush()`（加锁）。
    用 `buffer` 而非文本流，**规避 Windows 的 `\n`→`\r\n` 翻译**；所有日志只走 stderr。
 4. **CAD 未启动**：桥照常启动，`initialize`/`ping` 正常，`tools/list` 回 `-32603`（可重试）。
-5. **不擅自改写语义**：基座对未知工具回顶层 `-32601`（"Method not found"）语义上偏 JSON-RPC
-   方法层，严格说应是 `-32602` 或 `result.isError`。桥**不改写**；要修应改基座
-   `mcp_server.cpp: HandleToolsCall` 的码值分类。
+5. **不擅自改写语义**：桥只做忠实透传，错误码一律由基座决定。
+   （**2026-10-14 修正**：基座原先对未知工具回 `-32601`，语义偏 JSON-RPC 方法层；
+   按 MCP 规范「未知工具属于**协议错误**，示例码 `-32602`」已改为 `-32602` +
+   `"Unknown tool: <name>"`。改动点：`mcp_configParser.cpp: mcp_Tools::Call`
+   —— 只需改码值，`mcp_server.cpp: HandleToolsCall` 的协议错误白名单
+   `{-32700,-32600,-32601,-32602}` 已含 `-32602`，分类逻辑无需动。）
 
 ## 验证方法（重要，含踩坑）