fix(tls): cap non-streaming responses at 10 MB

[maxmad64bis]

⚠️ base-red inherited: #15306

Summary

Non-streamed TLS replies buffer with no size cap, so one huge upstream body can exhaust process memory. The reader loop adds each chunk without counting bytes, and it ignores a large declared content length. Buffered bodies now stop at 10 MB with a short JSON error.

Related Issues

• No linked issue — reproduced on the release base, no open issue covers it

Target Branch

• Base is the active release/v3.8.x branch (the highest open release/v*), not main
• New feature? From 3.8.55 on it is held with the v4-feature label for the v4 channel

Validation

• Change type: provider
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• tests/unit/tls-nonstreaming-response-limit.test.ts — 12 cases: 11 MB bodies get the bounded error, 1 MB bodies read unchanged, streamed replies pass through, and error statuses keep their status.

Coverage Notes

• open-sse/services/tlsClientBase.ts is covered by tests/unit/tls-nonstreaming-response-limit.test.ts (12 cases across the late-first-byte, non-2xx, non-SSE, native text and native byte paths).

Reviewer Notes

• Behavior: the 10 MB cap matches the chat path's existing guard, so huge upstream error pages no longer exhaust process memory; bodies over 10 MB now get the short JSON error instead of the full text, which fails requests that used to return huge bodies; plain 2xx replies answer 502 with it, while 429, 403 and other error statuses keep their status with the same short body; the cap doesn't apply to streamed replies.