[mpettibone]

max_fragmented_message_size is not applied to the first frame of a fragmented message. The check
only runs when a continuation frame arrives, so a client can open a message with a frame far over
the limit and Bandit keeps it in memory, unchecked, until the client chooses to send another frame.
If it never does, the frame is never checked.

Some background on what the option is for, since that is what makes this a problem. A WebSocket
message can be split across many frames (RFC 6455 §5.4), and the server has to hold the pieces until the final one arrives before it can hand the WebSock a complete message. That
buffer is per connection, it lives as long as the message stays incomplete, and the client decides
both how big it gets and how long it lives. max_fragmented_message_size is the operator's cap on
it. It is a different knob from max_frame_size on purpose: a single frame is handed to the
WebSock and freed, so it costs memory only while it's being processed, where a fragment is retained.
RFC 6455 §10.4 asks implementations to
limit "the total message size after reassembly from multiple frames" for exactly this reason, and
Bandit has had three advisories about the edges of this buffer, so the limit matters here.

Here is what the gap looks like. Take an app that expects small messages and sets
max_fragmented_message_size: 64_000 to keep reassembly buffers small, leaving max_frame_size
at its 8 MB default. A client sends one 8 MB text frame with FIN clear, then nothing but pings.
Bandit stores the 8 MB in fragment_frame, the pings keep the idle timeout from firing, and the 64
KB cap is never consulted, because dispatch_frame/3 only checks it in the two
Frame.Continuation clauses. The two clauses that start a fragmented message (a text or binary
frame with FIN clear) store the frame and record its size without a check. Open a thousand such
connections and the server is holding 8 GB that the operator believed was capped at 64 MB. The
first continuation frame, even a one byte one, would trigger the 1009, but a client doing this on
purpose won't send one.

Why this is a bug to fix rather than a limitation to document. The option's docs say it is "the
maximum size of a WebSocket message delivered across multiple continuation frames", and a frame
with FIN clear is by definition the start of such a message, so a first fragment over the limit is
already a message over the limit; nothing about the second frame changes that. The condition is
known the instant the frame arrives, and deferring the check hands the client control over whether
it ever happens. 1009 is defined as closing because the endpoint "has received a message that is
too big for it to process", which describes the opening fragment as well as it describes a later
one. Cowboy, for comparison, checks every fragment including the first against its limit.

The change is small. The two FIN-clear clauses now go through a start_fragmented_message/3 that
runs the existing oversize_message?/2 on the first fragment. Over the limit it closes with 1009
and the same "Received oversize fragmented message" error the continuation path uses; otherwise it
stores the fragment exactly as before. The continuation clauses and the single-frame path are
untouched.

Tests: two new ones next to the existing max_fragmented_message_size tests, one text and one
binary. Each sends a 1,010 byte opening fragment against a 1,000 byte limit and expects the 1009
immediately, with the WebSock's terminate seeing the same reason as for an oversize continuation.
Both fail on main, where nothing happens until a continuation arrives. Suite, format, credo and
dialyzer are clean.

[mtrudel]

Good catch!