exec_command startup failures are not emitted as command execution events

What issue are you seeing?

When an exec_command invocation fails before its process is created, the error is returned to the model, but no failed command-execution item is emitted to clients.

As a result, the tool attempt is completely absent from the TUI and app-server clients. The model may retry after receiving the error, which makes it appear as though only the later attempt happened.

This is not specific to a particular execution provider. It can occur whenever process startup fails, for example because an exec server rejects process/start, a remote environment disconnects, or process creation otherwise fails before the normal command lifecycle begins.

What steps can reproduce the bug?

1. Configure an exec-server-backed environment.
2. Make the server return a JSON-RPC error for process/start (disconnecting it immediately before the request produces the same class of failure).
3. Ask Codex to run any command with exec_command.
4. Observe that the model receives the tool error, but the command does not appear in the TUI or in the client's command-execution item stream.

The source path also shows the missing lifecycle branch:

• UnifiedExecProcessManager::exec_command_inner calls open_session_with_sandbox before constructing the ToolEmitter.
• If startup fails, it returns the error immediately.
• ToolEventStage::Begin is emitted only after startup succeeds, and no corresponding failure stage is emitted on the early-return path.

What is the expected behavior?

Every exec_command attempt should produce an observable command-execution item.

If process startup fails, clients should receive a failed CommandExecution containing the attempted command and startup error, even though no process was successfully created and no output stream was started.

Additional information

The TUI already handles a completed CommandExecution that has no matching in-progress item by rendering it as a standalone entry. Therefore, emitting a failed completion event from the core startup-error path should make the failure visible without requiring TUI-specific recovery logic.

This affects observability for all clients consuming the typed command lifecycle, not only terminal rendering.

Start by reading UnifiedExecProcessManager::exec_command_inner and the open_session_with_sandbox call, then trace how ToolEmitter and ToolEventStage::Begin normally create command lifecycle events. The fix is done when startup failures emit a failed CommandExecution containing the attempted command and error, and clients can observe it as a standalone item.