Define the boundary between ACP Agent Terminals and user Pane Actions

Description of the new feature

Intelligent Terminal currently exposes two command paths whose names and behavior overlap:

• ACP terminal/* lets an agent ask the client to execute and manage a command.
• request_terminal_actions proposes an action for a Windows Terminal pane and executes it only after user confirmation.

The current implementation blurs that boundary: ACP terminal commands may create real background WT tabs, while visually similar commands may instead appear as confirmation-backed Terminal Actions. The resulting execution location, ownership, visibility, and confirmation behavior can depend on which tool the agent chooses.

We need one precise mental model based on ownership:

• Agent Terminal: agent-owned execution used to investigate, build, test, or otherwise obtain information needed to continue the turn. It runs in a managed terminal attached to the Agent Pane, streams command/output/status there, and has an agent-controlled kill/release lifecycle. It must not implicitly mutate the user's pane or create a user-owned tab.
• Pane Action (currently Terminal Action): user-owned mutation of the terminal workflow, such as sending input to the active pane or opening a tab/panel. It is presented as a recommendation and executes only after explicit user confirmation. Once accepted, its lifecycle belongs to the user.

Decision rule: If execution exists so the agent can continue reasoning, use Agent Terminal. If the intended result is to change the user's terminal workflow, use a Pane Action.

Proposed technical implementation details

• Back ACP terminal/* with a private managed ConPTY/terminal entity instead of automatically creating a WT tab.
• Render command, cwd, live output, elapsed time, exit status, truncation, and Stop in the Agent Pane; retain a read-only snapshot after release.
• Merge UI updates by terminalId so terminal/create and later tool-call terminal content do not create duplicate cards.
• Keep Pane Actions as the only path for confirmed mutations of active panes, tabs, and panels.
• Do not automatically convert Agent Terminals into Pane Actions or vice versa; provide an explicit user-triggered Open in Terminal handoff if needed.
• Define Agent Terminal execution permission independently from Pane Action confirmation.
• Rename the user-owned concept to Pane Action or Terminal Recommendation to avoid collision with ACP terminal terminology.
• Complete ACP terminal semantics, including outputByteLimit and accurate truncated reporting.

Acceptance requires that the same command has predictable ownership, UI, permission behavior, and lifecycle regardless of the connected ACP agent implementation.

Start by tracing the ACP terminal/* path and request_terminal_actions path described in the issue, comparing their ownership, execution location, permission, UI, and lifecycle behavior. Define the boundary and implementation plan around managed Agent Terminals versus confirmation-backed Pane Actions; done means the acceptance requirements hold consistently for any connected ACP agent.