[AgentProtocol] Use elicitations for tool approvals and interactive choices

[mbleigh]

Parent tracking issue: #22702

Context

Interactive agent steps like tool confirmations and loop detection overrides should be driven by the protocol using the existing elicitation_request / elicitation_response mechanism. This ensures the TUI remains a "dumb" renderer of requests rather than managing complex backend state.

The existing ElicitationResponse type already supports action: 'accept' | 'decline' | 'cancel'. We can leverage this for tool approvals by making the content field optional for simple accept/decline flows. To correlate an approval elicitation back to the specific tool call, we will use a request ID convention.

Tasks

• Update ElicitationResponse type:
  • Make the content field optional (content?: Record<string, unknown>).
• Implement elicitation_request emission in LegacyAgentProtocol:
  • Tool Approvals: Map Scheduler pauses to an elicitation request. Use a correlation prefix for the ID: toolApproval:{toolRequestId}.
  • Loop Detection: Map loop warnings to a generic elicitation request using requestedSchema to define the "Keep" and "Disable" options.
• Update LegacyAgentProtocol.send() to intercept elicitation_response payloads and route them back to the internal services (Scheduler, LoopDetectionService) waiting for them.
• Refactor useAgentStream.ts to:
  • Listen for elicitation_request events.
  • Dispatch the appropriate UI component (e.g., rendering ToolConfirmationQueue when it detects the toolApproval: prefix).
  • Respond via agent.send({ elicitations: [{ requestId, action: 'accept' }] }).

Relevant Files

• `packages/core/src/agent/types.ts`: Update `ElicitationResponse` type.
• `packages/core/src/agent/legacy-agent-session.ts`: Update to emit elicitations and handle responses in `send()`.
• `packages/cli/src/ui/hooks/useAgentStream.ts`: Implement UI handlers for protocol-driven elicitations.

Acceptance Criteria

• All interactive pauses are protocol-driven via elicitations.
• Tool approvals can be responded to using only the `action` field.
• The UI correlates approvals to tools using the `toolApproval:{id}` convention.
• The UI remains completely decoupled from `Scheduler` and `LoopDetectionService` internals.