fix(llm): reject Bedrock event-stream frames above the 16 MiB maximum

[pacocartones]

Issue for this PR

Closes#44630

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

bedrock-event-stream.ts reads total_length from the frame prelude and waits for that many bytes. It's a 32-bit field, so a malformed response can declare up to 4 GiB. Nothing bounds the wait, and since the buffer is only compacted once a frame completes, appendChunk re-copies the whole accumulated window on every network chunk — cost is quadratic in bytes received. Measured with 16 KiB chunks after a 0xFFFFFFFF prelude: 16 MiB sent → 4.1 s / 166 MiB RSS; 64 MiB sent → 47.2 s / 650 MiB RSS. The stream then fails with the generic ended without a terminal finish event, so there's no diagnostic either.

AWS caps an event-stream message at 16 MiB. @smithy/eventstream-codec doesn't enforce it. This adds that check before the length gate, so an oversized prelude fails fast with the declared size in the message instead of buffering toward a frame that can never complete. Well-formed frames are unaffected — the check only fires above 16 MiB, which no valid Converse frame reaches.

How did you verify your code works?

Added a test to packages/llm/test/provider/bedrock-converse.test.ts that feeds a prelude declaring 0xFFFFFFFF through LLMClient.generate and asserts the framing error. Without the fix it fails with Provider stream ended without a terminal finish event; with it, it passes.

bun test in packages/llm: 298 pass on dev, 299 pass with this change, 0 fail. bun run typecheck clean.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR