fix(mcp): enforce no-transform on POST SSE responses

[RaviTharuma]

Summary

• leave MCP GET SSE responses unchanged because the SDK already supplies Cache-Control: no-cache, no-transform
• defensively add no-transform when a POST JSON-RPC message response is text/event-stream, closing the remaining compression/buffering gap independently of SDK version behavior
• preserve existing cache directives and leave non-SSE responses, including their encoding and Vary headers, untouched
• add focused coverage for POST streamed SSE, SDK-protected GET SSE, and non-SSE responses

This is the clean release-based replacement for closed #8291 and implements the owner-approved defense-in-depth scope for #8277.

Tests

• npm exec -- tsx --test tests/unit/mcp-sse-response-headers-8277.test.ts tests/unit/mcp-session-sweep.test.ts
• npx eslint open-sse/mcp-server/httpTransport.ts tests/unit/mcp-sse-response-headers-8277.test.ts
• npm run typecheck:core
• git diff --check

Closes #8277
Supersedes #8291

🤖 Generated with Claude Code

[RaviTharuma]

CI note: the failing fast-path shards include repository-wide baseline failures outside this PR’s changed files (for example DashScope video assertions appear on multiple unrelated PRs). The focused tests listed in this PR body pass locally. I am still checking for any failure attributable to this patch.

[RaviTharuma]

Maintenance update: rebased the single focused POST SSE commit onto the current release/v3.8.49 tip (c525a0f45) and force-pushed head cd067220e. GitHub reported the PR mergeable before the rebase, and the rebase completed without conflicts.

Fresh focused verification after rebase:

• npm exec -- tsx --test tests/unit/mcp-sse-response-headers-8277.test.ts tests/unit/mcp-session-sweep.test.ts — passed
• npx eslint open-sse/mcp-server/httpTransport.ts tests/unit/mcp-sse-response-headers-8277.test.ts — passed
• npm run typecheck:core — passed
• git diff --check origin/release/v3.8.49...HEAD — passed
• diff remains limited to open-sse/mcp-server/httpTransport.ts and tests/unit/mcp-sse-response-headers-8277.test.ts

No owner review or inline comments are currently pending. Broad fast-path failures on the prior run are outside these two files and match the repository baseline already observed on merged #8292/#8296; I have not modified unrelated code.

[RaviTharuma]

Concrete repository-baseline evidence for the broad gates, for reviewer reference:

• Merged fix(dashboard): stop sidebar RSC prefetch storms #8292 had failures in the same seven jobs: Docs Gates, Fast Quality Gates, Vitest, and all four Unit Tests fast-path shards: fix(dashboard): stop sidebar RSC prefetch storms #8292
• Merged fix(backend): add structure-aware chat admission #8296 likewise had failures in those same seven jobs: fix(backend): add structure-aware chat admission #8296

PR #8303 changes only the MCP transport helper and its focused regression test. I will inspect the current rerun for any changed-file failure, but will not fold unrelated baseline repairs into this PR.

[RaviTharuma]

Current rerun inspection is complete. No failure references either changed file (open-sse/mcp-server/httpTransport.ts or tests/unit/mcp-sse-response-headers-8277.test.ts). The failures remain the same unrelated baseline classes: provider-breaker ReferenceError, provider/model catalog assertions, env/docs/i18n drift, stale error-helper allowlist, and the existing auto-combo Vitest assertion.

PR-attributable checks are clean: DAST, change classification, merge integrity, both Semgrep checks, and no-new-ESLint-warnings all passed; focused MCP tests, lint, typecheck, and diff checks also passed after the latest-base rebase. The PR is currently MERGEABLE; the concrete blocker is repository-wide baseline CI requiring maintainer override/merge, as already demonstrated by merged #8292 and #8296.

[diegosouzapw]

Merged into release/v3.8.49 — thanks @RaviTharuma! Validated via local merge-train (32-core .113) + a per-file discriminator confirming zero regressions vs the pure release tip; CI reds on this PR were pre-existing base-red drift (tracked separately). 🙏