`tmux_batch`: one discoverable front door for multi-action batches

The ask

Give agents one obviously-named entrypoint for multi-action batches — tmux_batch —
the way claude-in-chrome exposes browser_batch. When an agent wants to run several tmux
actions in one turn, it should reach for a single tool by name, surfaced in the server's
own guidance, without having to know which batching mechanism or engine tier happens to
be active.

Why

There are now three distinct ways to batch, and an agent can discover none of them
from the server instructions:

• Base client-side fan-out — call_readonly_tools_batch / call_mutating_tools_batch
  / call_destructive_tools_batch (#79) and the homogeneous send_keys_batch (#49 / #78).
  These appear in no instructions segment, and the safety tier is chosen by which
  wrapper name the agent picks, up front, before it knows what its own operations need.
• A proposed typed single tool — #81 run_tmux_operations (typed ops compiled to
  native tmux ;-chains).
• Opt-in engine-ops plan tools — execute_plan / build_workspace (#87, behind
  LIBTMUX_MCP_ENGINE_OPS=1), backed by libtmux's deferred chainable plan language that
  smart-folds ops into ;-chains, with the async / control-mode engines adding a second
  batching level underneath.

Same goal — fewer, fatter calls — split across three surfaces, three names, one of them off
by default. The agent has no single word to reach for, so the fast path stays cold.

Desired behavior (acceptance)

• One memorable entrypoint — tmux_batch — that takes an ordered list of tmux operations
  and returns per-operation results.
• Discoverable from the guidance an agent reads at runtime, not only from docstrings and
  the Sphinx docs.
• The agent should not pre-select a safety tier by choosing a wrapper name; the entrypoint
  should derive its effective tier from the operations it is given and stay hidden/blocked
  when that exceeds LIBTMUX_SAFETY.
• It should route to the best available backend — the engine-ops plan language when that
  tier is enabled, the base wrappers otherwise — without the agent needing to know which.

Non-goals

• Not prescribing how it is implemented, named internally, or how routing is done.
• Not redefining the safety model, the homogeneous/heterogeneous split, or the
  self-bounded-wait exclusions.
• Not introducing a new workflow DSL beyond what #81 / #87 already decide; this is a
  naming + discoverability + convergence ask, not a new engine.

Prior art / relationship

• Ships today: send_keys_batch (#49 / #78), call_*_tools_batch (#79), run_command
  (#73 / #76).
• In flight: #81 run_tmux_operations (typed front door) and #87 engine-ops
  plan/watch tools (the smart backend: LazyPlan op-folding at the plan layer, plus
  async / control-mode dispatch batching at the engine layer — two batching levels).
• tmux_batch should converge with #81 and, when the tier is enabled, delegate to
  the #87 plan language rather than compete with either.
• Paired with the batching-reminder companion issue: #102.

Start by inspecting the server instructions and the existing batch entrypoints named in the issue, then read the related designs in #81 and #87. Done means one discoverable tmux_batch entrypoint accepts ordered operations, returns per-operation results, derives its safety tier, and routes to the best available backend.