Python: Improve orchestration exception handling

[TaoChenOSU]

Motivation and Context

Currently, exceptions that occur inside the orchestration actors are not properly surfaced to the caller as it happens.

Fixes: #12719

Description

This PR addresses the issue by introducing a new exception_callback that is hidden from the user but will raise exceptions that occurs inside the orchestration actors to the caller.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[moonbox3]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
agents/orchestration
agent_actor_base.py	96	15	84%	51, 84–91, 93, 139, 156, 193, 219, 236
concurrent.py	72	0	100%
group_chat.py	180	9	95%	111–113, 115, 286–288, 290, 356
handoffs.py	187	13	93%	256–258, 260, 272, 287, 298–299, 304, 316–319
magentic.py	294	56	80%	122–124, 256, 379, 447, 450, 457, 461, 463, 521–522, 524–525, 531, 533–534, 538, 566, 570, 580–582, 585, 590–595, 617, 629–630, 632, 637, 641–642, 644, 646–647, 652, 662–663, 666, 670–671, 677–678, 680, 708, 710, 719–723
orchestration_base.py	128	5	96%	66, 169, 174, 179, 202
sequential.py	64	0	100%
TOTAL	26558	4499	83%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
3654	22 💤	0 ❌	0 🔥	1m 57s ⏱️

[moonbox3]

LGTM. A few points for consideration either in this iteration or the next:

1. Should we add some exception metadata? Timestamp, agent_id, operation context to help the caller? Looks like we'll lose some context about where or why the exception occurred.
2. Should we add some logging around the exception points?
3. Are we tracking a docs update to explain to users how exceptions are now surfaced?

[ekzhu]

Looks good to me. Callback is simple to reason about.

Just a reminder that we will need to think about a different way to surface exception if the actors are remote in a distributed runtime -- we don't have to worry about that now.

[TaoChenOSU]

LGTM. A few points for consideration either in this iteration or the next:

1. Should we add some exception metadata? Timestamp, agent_id, operation context to help the caller? Looks like we'll lose some context about where or why the exception occurred.
2. Should we add some logging around the exception points?
3. Are we tracking a docs update to explain to users how exceptions are now surfaced?

1. We don't get the agent id in the original exception as it could happen in the LLM layer. I see the benefit of having the agent ID so I added an error log that captures it.
2. Error log added.
3. Good call out. I will work on that.