wpf_attach reports success:true when inspector injection failed

[gentledepp]

Summary

When injection fails, wpf_attach still returns success: true and reports the failure only in a secondary inspector_status string. An agent (or user) reasonably reads success: true as "attached", proceeds, and then gets bare, uninformative errors from every subsequent tool call.

Observed

wpf_attach(process_id=31792, auto_inject=true)
→ {
    "success": true,
    "process_id": 31792,
    "session_id": "c293…",
    "main_window_handle": "window_0x2615D2",
    "inspector_status": "Injection failed - …\\native\\x86\\WpfInspectorBootstrapper.dll not found"
  }

wpf_find_elements(text="Neu", visible_only=true)
→ "An error occurred invoking 'wpf_find_elements'."

The second message carries no indication that the cause was the failed attach two calls earlier. Diagnosing this required reading the release zip's file listing and then the repo's build files. (The underlying missing-DLL bug is #14; this issue is only about how the failure is surfaced.)

Why it matters here specifically

MCP tool results are consumed by LLM agents, which key off obvious signals like success. A truthful success: false — or at minimum an explicit inspector_injected: false boolean rather than failure information buried in prose — is the difference between an agent reporting the real problem immediately and it flailing through several tool calls first.

Suggested fix

• Return success: false when the inspector could not be injected, or if the partial-attach state is intentional, add an unambiguous machine-readable field (inspector_injected: false) and document that callers must check it.
• Make downstream tools fail with a message that names the cause, e.g. "No inspector in process 31792 — attach did not inject (WpfInspectorBootstrapper.dll not found)", rather than the generic An error occurred invoking '<tool>'.