Support opencode as a control host for the exec loop #4

Problem

The Forge hardcodes pi as the exec agent and Claude Code as the judge:

--exec-cmd  "pi --provider $PROVIDER --model $MODEL ..."
--judge-cmd "claude --dangerously-skip-permissions"

opencode is a supported control host everywhere else in this project — website/docs/control-host/opencode.md documents pointing it at a stack — but it cannot drive or be driven by a Forge.

Why this is not just a string swap

bin/lmstack-forge infers state from the terminal, and every inference is agent-specific:

• Idle detection compares two capture-pane reads. It assumes a redrawing UI, so a spinner or streaming token differs between captures.
• Pane padding differs per agent. pi keeps a status bar on the bottom row; Claude Code draws from the top and leaves the rest blank. That difference alone caused a bug where idle compared "" with "" and reported idle instantly.
• Submit timing. The Return has to be a separate send-keys after a settle or a booting TUI swallows it.
• refuse_shell matches on #{pane_current_command} to catch an agent that died and left a shell behind.

A third agent needs its own answers to all four, and getting any of them wrong fails silently rather than loudly.

What would close this

• A small per-agent profile (how it pads, how it signals busy, what its process name is) instead of behaviour baked into lmstack-forge
• tests/exec_test.sh coverage that exercises a top-drawing and a bottom-padded agent, as it now does
• opencode usable as either window

Also worth deciding

Whether the judge must be Claude Code. The judge rebases, pushes and opens PRs, so it needs stronger reasoning than the exec agent — but that is an assumption this ticket should test rather than assume.