Fix vc3d-mcp AppImage auto-launch on Linux

[AlexeyDrobkovStrikesBack]

Fix vc3d-mcp auto-launch of a VC3D AppImage on Linux

Repo: ScrollPrize/villa
Path: volume-cartographer/tools/vc3d-mcp
Branch: fix/vc3d-mcp-appimage-launch-linux

Summary

On Linux the MCP server's --launch auto-start is broken when the target
binary is a *.AppImage. _launch_command() builds the argv as
[binary, "--agent-bridge", ...], i.e. it passes --agent-bridge as
argv[1]. A VC3D AppImage is a multitool dispatcher (scripts/appimage/AppRun)
whose argv[1] selects which bundled executable to run. With --agent-bridge
in that slot, AppRun treats it as a tool name, fails to find it, prints an
"unknown tool" error and exits 2. The MCP server never sees the
VC3D-AGENT-BRIDGE: listening ... handshake and auto-launch never comes up.

The AppImage must be invoked with an explicit VC3D subcommand first:

VC3D-x86_64.AppImage VC3D --agent-bridge [--volpkg ...]

Fix

Teach _launch_command() to insert the VC3D subcommand when the binary is an
AppImage, and pass the GUI flags directly for every other target (Linux dev
build, macOS .app binary, Windows .exe) exactly as before.

def _launch_command(binary: str, volpkg: str | None) -> list[str]:
    command = [binary]
    if binary.lower().endswith(".appimage"):
        command.append("VC3D")
    command.append("--agent-bridge")
    if volpkg:
        command += ["--volpkg", volpkg]
    return command

The change is behavior-preserving for all non-AppImage paths: the resulting
argv is byte-for-byte identical to before for those cases.

Test

Added test_appimage_needs_explicit_gui_subcommand to
tests/test_runtime.py, asserting that:

• an AppImage path yields [appimage, "VC3D", "--agent-bridge"], and
• with a volpkg, [appimage, "VC3D", "--agent-bridge", "--volpkg", <path>].

The existing AutoLaunchTest cases already cover the non-AppImage paths
(/tmp/VC3D, Windows .exe, volpkg option) and are unchanged, so they double
as the regression guard that plain executables still take the flags directly.

Evidence

• Full vc3d-mcp suite: 164 passed, 2 skipped (skips are the live-bridge
  tests that need a running VC3D).
• Focused test_runtime.py: 22 passed, including the new case.
• Negative control: reverting server.py to the pristine upstream version
  makes the new test fail with exactly the broken argv
  ['/tmp/VC3D-x86_64.AppImage', '--agent-bridge'] (missing the VC3D
  subcommand), confirming the test actually exercises the bug.

Verified end-to-end on Linux: a freshly built VC3D-bridge.AppImage now
auto-launches from the MCP server and reaches the listening handshake, where
before it exited 2 on an unknown-tool error.

[vercel]

@AlexeyDrobkovStrikesBack is attempting to deploy a commit to the scroll Team on Vercel.

A member of the Team first needs to authorize it.