[enhancement] Operator-agent interactive-CLI protocol in seed prompt + behavioral-eval scenario for the dropped-first-message failure

[serge-ivo]

Summary

Two cheap, high-leverage improvements that don't depend on the runner changes in #481 / #482 and can ship immediately to stop the currently-deployed Operator agent from silently dropping input.

Context

In production (instance Heartfull (tmux) cda75e28-…, trace f04b6224), the Operator agent:

1. Reported "Claude Code is up and ready" the instant it launched claude, before the TUI painted.
2. Sent the user's message into a still-shell pane (serge-ivo@Mac platform % claude) and it was dropped.
3. Recovered only because the user said "Check again."

The tool descriptions already state the send_keys-vs-run_command distinction (connectors/tmux.ts:105-130, :79-102), but the agent's own seed prompt says nothing about the interactive-CLI protocol. Confirmed gap — the tmux Operator / Single-Pane Operator seeds (migrations/0072_seed_tmux_operator_agent.sql, 0112_seed_single_pane_operator_agent.sql) and connector-tool-prompt.ts contain no instruction to (a) wait for CLI readiness before typing, (b) press Enter to submit, or (c) re-capture to verify a keystroke landed.

Part A — Operator-agent interactive-CLI protocol (seed prompt + connector-tool-prompt)

Add an explicit protocol to the tmux/single-pane Operator seeds (and/or the terminal-connector block in connector-tool-prompt.ts):

• After launching an interactive CLI (claude/codex/grok), do not assume it is ready — re-capture until its input prompt is showing before typing. Never report "ready" from the launch call alone.
• To submit a message to a running CLI, send the text and Enter (use send_message once [enhancement] Encode the interactive-CLI protocol in a high-intent terminal_send_message tool (text + Enter + settle + confirm) instead of leaving send_keys/Enter to the model #482 lands; until then send_keys with keys:["Enter"]).
• After sending, re-capture and confirm the pane changed. If it didn't, the input didn't land — resend; do not report success.

This mirrors the existing read-side grounding doctrine (agent-think.ts:557-563) on the write side, in prompt form, as an immediate mitigation ahead of the structural fix.

Part B — Behavioral-eval scenario + trace observability

• Add this incident as a regression scenario in the planned PAGS behavioral-eval suite (MCP-driven): launch a CLI in a fresh tmux session → send a first instruction → assert it actually lands (pane changes / CLI starts working), not a false "up and ready." This is exactly the prompt-position / dogfooding class the eval suite was proposed to cover.
• Trace observability: agent_trace currently stores a truncated tool message, so the exact tmux_send_keys args (was keys:["Enter"] passed?) could not be recovered when debugging this. Persist structured tool args/results (or at least key args) in agent_events so write-path failures are diagnosable from the trace alone.

Acceptance criteria

• Operator seed prompt(s) include the wait-for-ready / Enter-to-submit / resend-if-unchanged protocol.
• A behavioral-eval scenario asserts a first instruction lands in a freshly-launched tmux CLI.
• agent_trace / agent_events retains enough tool-arg detail to tell whether a send included Enter.