bug(vba): execute_macro hangs with no timeout on a modal macro #97

Summary

execute_macro (→ ISldWorks::RunMacro2) blocks the adapter's COM executor thread until the macro returns. A macro that shows a modal dialog (MsgBox, a userform, an error prompt) hangs the whole MCP server with no timeout — a ~2m17s hang was observed live before the dialog was dismissed by hand.

Why

RunMacro2 is synchronous and runs on the single STA ComExecutor thread that every COM call shares. While it is parked on a modal dialog:

• no other SolidWorks tool call can make progress,
• there is no timeout, so an unattended run hangs indefinitely,
• the caller gets no signal about why it is stuck.

Suggested scope

• A configurable timeout on execute_macro; on expiry, return a structured error naming the likely cause (modal dialog / long-running macro) instead of hanging.
• Consider running RunMacro2 on a dedicated short-lived thread so a timeout can abandon the wait without wedging the shared executor (COM apartment rules apply — needs care).
• Optionally detect a foreground modal window owned by SLDWORKS.exe and surface that in the error.
• Document that macros invoked through the tool must not be interactive (no MsgBox, no userforms).

Notes

Follow-on from #91. Bug: an interactive macro should fail cleanly, not hang the server.