Fix/clean error handling for runners

[JohnPraveenYL]

Description

This PR fixes inconsistent and noisy runtime error handling across Agent Kernel runners, with a focus on issue #247.
It standardizes user-facing error messages, prevents traceback-heavy CLI output in normal usage, and stabilizes example environments (especially LangGraph) so failures are reproducible and readable.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test update
• CI/CD update
• Other (please describe):

Related Issues

Fixes #247
Relates to #247

Changes Made

• Added centralized user-facing error normalization for provider/runtime failures (including 503/429/high-demand style failures).
• Updated runner error handling consistency across ADK, CrewAI, LangGraph, and OpenAI to return clean AgentReplyText errors instead of bubbling raw framework exceptions.
• Improved ADK runner behavior to avoid noisy thread-level exception leakage and avoid None-text reply issues.
• Improved LangGraph content extraction and exception handling paths for robust empty/non-text responses.
• Updated CLI logging behavior to keep default output user-friendly (single-line errors) and keep full traces at debug level.

Testing

• Unit tests pass locally
• Integration tests pass locally
• Manual testing completed
• New tests added for changes

Manual checks performed:

• Built package locally (build.sh).
• Ran demo flows for ADK, OpenAI, CrewAI, and LangGraph.
• Verified simulated failure paths produce clean user-visible errors and CLI remains interactive.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Screenshots (if applicable)

N/A

Additional Notes

[amithad]

We are printing the log here anyway right?

[JohnPraveenYL]

yes, but the user sees only the short error message and the debug log keeps the full traceback for troubleshooting.
So it is useful, but not required for normal output.

[amithad]

Why check "run_async"?

[JohnPraveenYL]

In our case, I kept run_async because I saw issues when it was not checked and the code broke in some setups. Some runner versions support async and some do not so this check helps the code work safely in both cases.