tmux_batch: one discoverable front door for multi-action batches #101

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 (Add tier-aware MCP tool batching #79) and the homogeneous send_keys_batch (Compose / bulk operations: run multiple actions in one MCP tool call (start with send_keys) #49 / Add send_keys_batch and clarify terminal workflow primitives #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 — Typed tmux operation chains #81 run_tmux_operations (typed ops compiled to
  native tmux ;-chains).
• Opt-in engine-ops plan tools — execute_plan / build_workspace (feat: opt-in engine-ops chained plan tools and watchers #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 Typed tmux operation chains #81 / feat: opt-in engine-ops chained plan tools and watchers #87 already decide; this is a
  naming + discoverability + convergence ask, not a new engine.

Prior art / relationship

• Ships today: send_keys_batch (Compose / bulk operations: run multiple actions in one MCP tool call (start with send_keys) #49 / Add send_keys_batch and clarify terminal workflow primitives #78), call_*_tools_batch (Add tier-aware MCP tool batching #79), run_command
  (Add atomic run/wait/capture tool with exit status #73 / Harden tmux MCP tool surface #76).
• In flight: Typed tmux operation chains #81 run_tmux_operations (typed front door) and feat: opt-in engine-ops chained plan tools and watchers #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 Typed tmux operation chains #81 and, when the tier is enabled, delegate to
  the feat: opt-in engine-ops chained plan tools and watchers #87 plan language rather than compete with either.
• Paired with the batching-reminder companion issue: Nudge agents toward batching: a post-single-call system-reminder #102.