run_command: tmux completion wrapper breaks over SSH panes (error connecting to socket)

Description

run_command wraps each authored command with a completion-sync wrapper (see
src/libtmux_mcp/tools/pane_tools/io.py, the status_cmd / signal_cmd
construction):

(
<command>
); s=$?; tmux set-option -p -t <pane_id> @s_<id> "$s"; tmux wait-for -S r_<id>

The tmux set-option and tmux wait-for -S fragments execute inside the
pane's shell. When the pane's shell is an active SSH session, that shell
lives on a remote host that has no tmux server (or a different socket), so both
calls fail in the pane with:

error connecting to /tmp/tmux-1001/default (No such file or directory)
error connecting to /tmp/tmux-1001/default (No such file or directory)

(the socket path carries the remote user's uid).

Steps to reproduce

1. In a tmux pane, run ssh user@remote-host and log in.
2. Have the agent call run_command in that pane (e.g. git status).
3. Observe the two error connecting to .../default lines printed in the pane.

Actual behavior

• The user's command still runs and its output is visible, so it looks like it
  "works".
• But the wait-for channel is never signalled, so the server-side wait runs to
  the LIBTMUX_MCP_WAIT_MAX_SECONDS ceiling and the call reports a
  timeout-based result.
• The @s_<id> pane option is never set, so no exit status can be read back.
• The error lines are printed into the pane a human may be watching.

Expected behavior

One or both:

1. Document the limitation — gotchas.md, troubleshooting.md, and/or the
   run_command tool description: run_command assumes the pane's shell can
   reach the same tmux server the MCP talks to. In SSH panes, compose
   send_keys + a shell-level completion marker + wait_for_text +
   capture_pane instead.
2. Detect it — e.g. check pane_current_command (or pane_in_mode) before
   wrapping: when the pane is ssh, either skip the wrapper and warn in the
   result, or fail loudly with a hint, rather than sending a wrapper that is
   guaranteed to emit errors on the remote.

Workaround that works (shell marker, no tmux in the payload)

send_keys(pane_id, "git status; echo __MCP_DONE_$?__", enter=True, literal=True)
wait_for_text(pane_id, patterns=["__MCP_DONE_"], timeout=120)
capture_pane(pane_id)

The marker is pure shell and runs on the remote — no tmux call, so no error
lines; the exit code is read from the __MCP_DONE_<n> line in the capture.

Environment

• libtmux-mcp 0.1.0a22 (FastMCP 4.0.3)
• tmux 3.4 on WSL2 Ubuntu (local); remote host is a plain Ubuntu 24.04 box
• MCP server addresses the local tmux server; the affected pane is a shell that
  has logged in over SSH

Start in src/libtmux_mcp/tools/pane_tools/io.py at the status_cmd and signal_cmd construction, then reproduce run_command in an SSH-backed pane. Review the existing run_command description and documentation files named in the issue. Done means the chosen behavior is documented or detected clearly, without remote tmux errors or timeout-based completion results.