fix(stream): scan the whole new chunk, not just the window tail

[aymandakirgh]

Why

createStreamGuard / guardTextStream scan only the last window (8192) chars of the accumulated buffer on each push(). The window is anchored to the tail of the buffer, so when a single push is larger than the window the leading bytes of that chunk are never scanned.

This is a realistic path, not a contrived one: the guard is documented to compose with "any async iterable of strings", so adapting a non-streaming completion into it yields the entire output as one chunk. A secret/PII near the start of a >8 KB answer then slips through.

Reproduced — identical content, opposite verdicts:

Delivery	Verdict
"Contact alice@example.com " + 8300×"x" as one chunk	blocked = false ❌ (PII leaks)
same text split into small chunks	blocked = true ✅

Detection depended on chunk size, not content.

What

Scan the last chunk.length + window chars: the full chunk just appended (leading bytes always inspected) plus window chars of prior context to preserve cross-chunk straddle detection (<scr + ipt>). Per-push cost stays O(window) for normal token-sized chunks and is O(window + chunk) only for an outsized single push — the cost of actually inspecting content you just emitted.

Verification

• npm run typecheck ✅ · npm run lint ✅ · npm test → 307 passed / 1 skipped ✅
• 2 new regression tests: PII in a single >window chunk is blocked; verdict is chunk-size-independent for identical content.