fix(protect): don't buffer live streams (SSE) in response screening

[patchstackdave]

Why

Response screening buffers the whole body before deciding (redact/block). For a live stream — text/event-stream, the standard shape for LLM token streaming, which AI-built apps lean on heavily — readTextResponse reads the body until done, i.e. until the entire stream ends. So the client sees nothing until generation completes: incremental streaming is broken. Flagged in the output-filtering review as the blocker to enabling response screening by default on Node/Express.

What

Exclude text/event-stream from screening on both paths:

• fetch path: readTextResponse returns null (skip) for an event-stream → screenResp hands back the original response untouched.
• node/express path: the isTextCT gate returns false for event-stream → the buffered-response wrapper passes chunks straight through.

A live stream now passes through unbuffered and unscreened — the same fail-open tradeoff already used when a body exceeds the screen cap. (Non-stream text responses are screened exactly as before.)

Tests

tests/protect/response-streaming.test.ts — a never-closing SSE stream returns promptly (<500ms) and as the original object (before the fix it would await the stream forever), and a normal text response is still screened. 628 pass; typecheck clean.

🤖 Generated with Claude Code

[coderbuds]

Adds event-stream checks to skip buffering live SSE responses.

🎯 Quality: 100% Elite · 📦 Size: Small

📈 This month: Your 49th PR — above team average · Averaging Elite

_{See how your team is trending →}

[patchstackdave]

/review