fix: prevent in-process callback failures from breaking calls

[1fanwang]

Fixes #3434

With an in-process client, a progress callback exception turns a successful tool call into UnexpectedToolError. Notification handler exceptions also escape through notify().

DirectDispatcher now logs and contains those failures, matching JSONRPCDispatcher.

Motivation and Context

The transport should not let callback code change a protocol outcome. Request handler failures still become MCPError.

How Has This Been Tested?

The contract tests fail on clean origin/main with only the tests applied, then pass with the fix.

Raw logs

$ uv run --frozen pytest tests/shared/test_dispatcher.py \
    -k 'progress_callback_exception_does_not_fail_request or notification_handler_exception_does_not_reach_sender' -q
# clean origin/main with tests only
2 failed, 2 passed, 48 deselected

# with this fix
4 passed, 48 deselected

$ PYTHONWARNDEFAULTENCODING=1 uv run --frozen coverage run -m pytest tests/shared/test_dispatcher.py -q
52 passed

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• Not yet assigned, and the issue has no help wanted label.
• I have disclosed any AI assistance and can explain the change in my own words.
• I have read the relevant MCP documentation.
• My code follows the repository's style guidelines.
• New and existing dispatcher tests pass locally.
• I have added appropriate error handling.
• No documentation update is needed because this restores the existing contract.

Additional context

I used GitHub Copilot CLI to inspect the dispatcher paths, write the patch and tests, and draft this pull request. I reviewed the change and verified the results.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3434.

If a maintainer assigns you to #3434, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.