ACP session/cancel emits agent_error for MessageAbortedError before cancelled result

[truenorth-lj]

Summary

When ACP session/cancel interrupts an in-flight prompt, the prompt result should represent a user cancellation, not an agent failure. In the agent_error event path added for failed LLM turns, MessageAbortedError should be filtered out.

Reproducer

1. Start an ACP session/prompt that streams for long enough to cancel.
2. Send ACP session/cancel while the turn is still active.
3. Observe the emitted session/update frames and final prompt result.

Expected

The final prompt result is:

{ "stopReason": "cancelled", "_meta": {} }

No agent_error session/update is emitted for the same user-cancel action.

Actual

Before the final cancelled result, the stream can emit:

{
  "sessionUpdate": "agent_error",
  "error": { "type": "unknown", "message": "Aborted", "retryable": true },
  "stopReason": "error"
}

followed by:

{ "stopReason": "cancelled", "_meta": {} }

Why this matters

ACP clients receive both an error and a cancellation for one user action. Since MessageAbortedError is the normal result of session/cancel, surfacing it as agent_error makes an intentional stop look like an agent/LLM failure.

Proposed fix

In the ACP event handler, ignore session.error events whose error name is MessageAbortedError. The prompt RPC result remains responsible for reporting stopReason: "cancelled".

Related: #25899, #26352

[Keesan12]

This kind of double-reporting is where a small failure taxonomy really pays off. cancelled_by_user, interrupted, and agent_error should be terminally exclusive states, otherwise downstream clients can't tell whether to retry, alert, or just close the spinner.

If you still want the internal abort exception for tracing, it probably belongs in a hidden receipt field rather than the public session outcome.

[Keesan12]

I'd treat session/cancel as an authority event, not an execution failure.

If the wire emits both agent_error and cancelled for the same action, operators can't tell whether the model failed or the human intentionally intervened. A clean rule is: user-initiated aborts may emit a cancellation lifecycle event, but they should never enter the generic error lane unless cleanup itself fails.

That keeps stop reasons composable.