Real-server proof for MCP dispatch refusal messages

No tests or mocked services were used. Each side was installed and run from its
own detached worktree, with T3CODE_DEV_SEED=0 vp run dev and its own fresh T3 home.
Add an empty scratch git repository through `t3 project add`.
Enable provider instance opencodeAcp with driver acpRegistry, source local,
commandPath opencode and commandArgs ["acp"].

Start a thread using:
  t3 thread start <project> --provider opencodeAcp --model openai/gpt-5.6-luna --wait
Prompt the agent to run exactly one shell command:
  python3 <path-to-lock-call.py> <checkout-root>

lock-call.py must be outside the checkout. Its output directory is its own parent.
The script inherits the real ACP session's T3_ACP_MCP_ENDPOINT and
T3_ACP_MCP_AUTHORIZATION. It never saves or prints those credentials.
It takes a SQLite BEGIN IMMEDIATE write lock, starts its 30-second release timer,
waits one second, and calls the real acp-mcp-call create_threads CLI.
The reply is saved immediately, before releasing the lock. The script remains
silent to the agent until release so tool-output ingestion does not race the call.

The .cast files record timestamped output directly as each operation happens.
The MP4 files render those original timed events at 4fps, at the same viewport,
font and theme on both sides. PNGs are the final frames of those recordings,
not screenshots of the web client. Reply JSON files contain the actual MCP result.

The lock can also break provider event ingestion and leave an agent run failed.
That is independent of this proof: the captured isError reply comes from the
create_threads MCP call while its provider run is active. A base server needed
restarting before the recorded repeat because it kept a write transaction open.