Give each modern SSE response its own header list

[guptaishaan]

Fixes #3701

SSE responses on the 2026-07-28 entry now get their own header list instead of the shared module-level _SSE_HEADERS.

Motivation and Context

handle_modern_request passed _SSE_HEADERS itself to http.response.start. ASGI middleware that appends to message["headers"] in place mutated the shared list, so headers piled up and leaked across responses for the life of the process. The fix is list(_SSE_HEADERS).

Thanks to @mgoldsborough for the report and the repro.

How Has This Been Tested?

• Added test_sse_mode_gives_each_response_its_own_header_list. It sends two SSE requests through a send wrapper that appends a header in place. It fails before the fix (['abc', 'abc'] == ['abc']) and passes after.
• tests/server/test_streamable_http_modern.py and tests/interaction/transports/test_hosting_http_modern.py pass. ruff and pyright are clean on the touched files.
• Run on a Linux CPU-only environment. I did not run the full suite or the exact script from the issue.

Breaking Changes

None.

Types of changes

• 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 change)
• Documentation update

Checklist

• I am assigned to the linked issue (or it is labeled help wanted, or I'm a maintainer)
• I have disclosed any AI assistance and can explain the change in my own words
• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

AI disclosure: this change was prepared by an automated Claude Code run (reproduction, fix, and test). The issue reporter also used Claude Code for the issue draft. I am not assigned to the issue.

[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 #3701.

If a maintainer assigns you to #3701, 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.