Address PersistentChatClient not handling streaming content errors

[rogerbarreto]

Motivation & Context

Was not clear when a misconfigured tool was used, resulting in non conventional and unexcepted empty response.

cc: @stephentoub

Solution

This change adds a Error Handling behavior setting to the IChatClient:

1. Throws an exception with the reasoning. This is the default behavior.
2. If set to off, the error is represented as an ErrorContent in message/chunk Contents.

[Copilot]

Pull request overview

This PR adds error handling behavior to the PersistentChatClient to make streaming content errors from misconfigured tools more visible. By default, the client now throws exceptions when content errors occur, but can be configured to return errors as ErrorContent objects instead.

Key changes:

• Added throwOnContentErrors parameter to AsIChatClient extension method (defaults to true)
• Implemented error detection for failed runs with LastError in the streaming response handler
• Added comprehensive test coverage for both throwing and non-throwing error handling modes

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
PersistentAgentsChatClient.cs	Adds error handling logic to detect failed runs and either throw exceptions or add ErrorContent based on the throwOnContentErrors setting
PersistentAgentsClientExtensions.cs	Updates the AsIChatClient extension method signature to include the new throwOnContentErrors parameter
PersistentAgentsChatClientTests.cs	Adds new test TestContentErrorHandling with mock transport to verify both error handling behaviors, plus helper methods for creating mock responses
assets.json	Updates test assets tag reference

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Azure.AI.Agents.Persistent

[stephentoub]

Why does this need to be configurable? In the case where this fails, it sounds like there won't be any other content, so someone who wanted an ErrorContent could catch the exception and create their own. And presumably we think someone wanting to do that is rare.

[rogerbarreto]

Why does this need to be configurable? In the case where this fails, it sounds like there won't be any other content, so someone who wanted an ErrorContent could catch the exception and create their own. And presumably we think someone wanting to do that is rare.

There will be metadata content, available as the ChatResponse or individual chunks (Streaming) that doesn't surface as Text contents, so this metadata could be desireable in those rare instances.