fix(gateway): send CORS headers on session chat/stream and run-events SSE

[gaomind]

Problem

Two SSE endpoints return 200 text/event-stream without any Access-Control-* headers, so a cross-origin browser client is forbidden from reading the response body:

• POST /api/sessions/{session_id}/chat/stream
• GET /v1/runs/{run_id}/events

The failure mode is nasty: the request succeeds server-side — the agent runs and consumes model tokens — but the browser surfaces only a generic Failed to fetch. Both surfaces are advertised to browser clients via /v1/capabilities (session_chat_streaming, run_events_sse), so as shipped the capability announcement is not honoured for cross-origin callers.

Root cause

The CORS middleware cannot inject headers into a web.StreamResponse after prepare() flushes them. _write_sse_chat_completion and _write_sse_responses already resolve CORS up front for exactly this reason (the comment is in the file), but these two exits were missed.

Fix

Apply the same idiom at both sites: resolve self._cors_headers_for_origin(origin) before constructing the StreamResponse. Same configured-allowlist policy as every other endpoint — nothing is opened up that the non-streaming endpoints don't already allow, and callers without an Origin header keep exactly the old header surface.

Tests

Three tests added to tests/gateway/test_session_api.py:

• chat/stream carries Access-Control-Allow-Origin for an allowed origin
• chat/stream without Origin adds no CORS headers (negative — non-browser callers unchanged)
• run-events SSE carries Access-Control-Allow-Origin

All three fail without the fix; full tests/gateway/test_session_api.py suite passes with it.

Found while integrating a cross-origin SPA that talks directly to the gateway.

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Related to #72945 (session-chat stream) and #6367 (run-events SSE). This PR covers both distinct handlers with the same established pre-prepare CORS pattern, so it is an omnibus competing fix rather than a duplicate of either single-endpoint PR.

[gaomind]

Thanks for the triage link-up — to make the relationship explicit for reviewers:

• fix(api-server): resolve CORS headers on session chat stream SSE response (#72892) #72945 fixes only POST /api/sessions/{session_id}/chat/stream
• fix(api_server): add CORS headers to /v1/runs/{run_id}/events SSE endpoint #6367 fixes only GET /v1/runs/{run_id}/events
• This PR covers both handlers with the pre-prepare CORS pattern already established in the gateway, so the two SSE surfaces stay consistent and a second follow-up round-trip is avoided.

Credit to @Tranquil-Flow and @kawanoii for identifying the per-endpoint gaps first. If maintainers prefer landing either of those, I'm happy to rebase this down to the remaining endpoint — otherwise this can land as the single omnibus fix.