Track terminal execution capabilities for PTY and non-PTY command output

[anthonykim1]

AHP currently exposes terminal output through ToolResultTerminalContent / ahp-terminal: and command completion metadata through ToolResultTerminalCompleteContent.

During discussion in #314, we intentionally avoided specifying whether an ahp-terminal: channel is always PTY-backed or may also represent non-interactive command execution, because clients currently do not have a protocol-supported way to discover the backing behavior.

We should discuss whether AHP needs terminal or command-execution capability metadata so clients can make rendering and interaction decisions without guessing from implementation details.

Questions to discuss

• Should ahp-terminal: always mean PTY-backed terminal, or can it represent a broader command execution surface?
• If non-PTY command output can use terminal channels, what capabilities should clients be able to inspect?
• Do we need fields such as supportsInput, supportsResize, supportsVT, stdout/stderr separation, or other execution/rendering hints?
• Should this capability metadata live on TerminalState, a command execution state shape, or a future channel kind?
• How should clients render retained command completion metadata when no live terminal channel exists?

Context

• Add shell exit tool result metadata #314 added ToolResultTerminalCompleteContent as retained command completion metadata.
• It optionally references an ahp-terminal: resource when live output was exposed.
• We removed wording that implied terminal channels may not be PTY-backed until there is a concrete capability-discovery story.

Goal

Define a protocol-level way for clients to determine what terminal or command execution behaviors are available, rather than assuming PTY semantics or encoding host implementation details in naming.