Nudge agents toward batching: a post-single-call system-reminder

[tony]

The ask

After an agent makes a lone tmux tool call that could have travelled in a batch, deliver a
short system-reminder-style nudge encouraging it to batch next turn — the way
claude-in-chrome nudges toward browser_batch after a single MCP call:

You used a single tool call this turn. Prefer tmux_batch to execute multiple actions in
one call — it is significantly faster. Batch your next sequence of sends, waits, captures,
and layout changes together.

This is the runtime, in-loop counterpart to the tmux_batch front door (#101): the tool
gives the agent something to reach for; the reminder teaches it to actually reach.

Why

Every MCP tool call is a round-trip and an agent turn. The batch surface exists — and under
engine-ops (#87) it is genuinely powerful, with two levels of folding/pipelining — but
agents rarely find or use it. The generic wrappers appear in no server instructions
segment, and nothing at runtime points an agent back toward batching once it has fallen into
one-call-at-a-time behavior. Every reactive string the server emits today is error-path only
(bad-argument suggestions, tier denials, per-op batch rejections); none fires on a clean
single call. Static docs do not change in-loop habits; a per-call reminder does.

Desired behavior (acceptance)

• After a qualifying single (non-batch) tmux call, the agent receives brief guidance —
  delivered as guidance, not an error — that names the concrete batch tool to use.
• Tier-aware target. Name the engine-ops plan tools (execute_plan / build_workspace)
  when LIBTMUX_MCP_ENGINE_OPS=1; otherwise send_keys_batch / call_*_tools_batch (or
  tmux_batch once tmux_batch: one discoverable front door for multi-action batches #101 lands).
• Never blocks, delays, or alters the tool's own result. Batching stays opt-in — the
  reminder never forces a batch or rejects a single call.
• Restrained enough not to fire on every call forever (behavioral intent — thresholds and
  suppression are for the implementer).

Non-goals

• Not prescribing middleware / hook design, per-turn call-count tracking, or thresholds.
• Not forcing batches, changing tool results, or altering safety tiers.
• Not a new batch tool — that is tmux_batch: one discoverable front door for multi-action batches #101; this issue only adds the reactive nudge toward it.

Prior art / relationship

• No existing ticket does this. Surface invocation context (in tmux? server running? which socket?) and make tmux-server auto-start explicit #96 / Add a self-location primitive (where_am_i): agents must dump every pane on the server to learn which pane they are in #93 (PR Add caller-aware discovery and explicit startup #99) surface invocation context /
  self-location through static instruction segments frozen at import — not a post-call
  adaptive reminder. wait_for_channel and signal_channel block the FastMCP event loop (sync subprocess.run) #18 merely quotes Claude Code's own client-side MCP-disconnect message.
• The nudge points agents at the batch surface tracked by 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 (send_keys_batch),
  Add tier-aware MCP tool batching #79 (call_*_tools_batch), Typed tmux operation chains #81 (run_tmux_operations), feat: opt-in engine-ops chained plan tools and watchers #87 (engine-ops plan tools), and
  the tmux_batch front door (tmux_batch: one discoverable front door for multi-action batches #101).