Shell wrappers: a plugin-settable per-call "run to completion" flag, and an event when a promoted task ends #640

Summary

A plugin that wraps the shell tool can't make one call run to completion, and can't tell when a promoted call really ends. This matters for wrappers that must clean up after the command: for example, a sudo wrapper that removes cached credentials, or a redaction step on the final output.

Today a foreground call returns before the command exits in three cases:

• after the wait window (auto-promotion, 15 s by default), with {status: "running", taskId};
• on any steer-delivered prompt while bash.detach_on_user_message is on (since 0.61 queued deliveries no longer detach, OpenCode 2: a queue-delivered prompt detaches a foreground wait:true call the moment it is enqueued #563);
• at bash.worker_wait_max_ms for wait: true.

The only ways to prevent this are global: bash.background: false (#124) or bash.detach_on_user_message: false. A plugin can't set them for one call, and turning them off for every command changes the agent experience for the session. The plugin's own cleanup (its finally after execute returns) therefore runs while the command is still running.

Proposal

1. A per-call argument a plugin can set in tool.execute.before, for example detach: "never", meaning: no auto-promotion and no detach on messages. The command runs until it exits or reaches its timeout. Agents need not see the argument; it is enough that a plugin can set it.
2. A plugin-visible event when a promoted or background task ends: task id, session, exit code or signal, and a reference to the final output. A wrapper can then run its cleanup at the real end.

Checked on main (da592c3): the shell's agent arguments are command, timeout, workdir, description, wait, background, pty, ptyRows, ptyCols, compressed, sandbox. The internal block_to_completion the plugin computes (tools/bash.ts:720) can't be set from outside. Related: #398 (a config cap for wait: true).