[fix] Fixing Default maxFragments still allows memory exhaustion Dos

[codepawpaw]

Issue: #2331

Problem:

The GHSA-96hv-2xvq-fx4p fix added the count-based guards maxFragments and maxBufferedChunks, but their defaults are high enough that a default-configured server can still be OOM-crashed by a single unauthenticated peer.

Both guards count parts, and the only byte-based guard (maxPayload) counts payload bytes only. Nothing accounts for the per-Buffer-view object overhead (~128 B each). An attacker can exploit this:

Send a text frame with FIN=0, then maxFragments - 2 one-byte continuation frames, and never send FIN.
The message never completes, so the fragment array is retained indefinitely.
_totalPayloadLength stays ~128 KB (far below maxPayload of 100 MB) and the fragment count stays just under maxFragments (131072), so no guard ever fires.
Reproduced on the current tree (default server options): ~0.87 MB of wire traffic pins ~13–16 MB of heap (≈15× amplification). A few dozen such connections OOM-kill a default-heap Node process.

Fix
Two complementary changes:

1. New maxBufferedBytes option (structural fix). Charges a fixed per-part overhead (BUFFER_OVERHEAD = 128) on top of payload bytes, so the limit bounds the memory actually pinned rather than only the payload size. Enforced on all three retention paths — buffered input chunks (_write), uncompressed fragments (getData), and compressed fragments (decompress). Exceeding it emits WS_ERR_TOO_MANY_BUFFERED_PARTS (close code 1008).

2. Lowered the default count limits (defense-in-depth)
   maxBufferedBytes defaults above maxPayload (100 MiB) so that a legitimate max-size message is never rejected; the tighter count defaults are what cap per-connection retained memory in the default configuration

New behavior is opt-in at the Receiver level (maxBufferedBytes defaults to 0 = disabled there). The lowered maxFragments/maxBufferedChunks defaults are a behavior change only for peers sending an unusually large number of fragments/chunks in a single message, all limits remain configurable (set to 0 to disable).