fix(collect): keep the request under the server's 10 MB limit

[qfroot]

qf collect no longer sends a request the server is certain to reject.

Before: parsers cap inline (non-image) attachments in decoded bytes per parsed file (1 MiB each, 8 MiB per file). On the wire, attachments are base64, about a third larger, and one collect can merge several files. So a run could still assemble a body over /collect's 10 MB limit. The server answered with a 413 and the whole launch was lost; qf only printed a warning beforehand.

Now:

• Measure what is sent: after screenshots are offloaded to blob storage, qf measures the exact body it will send. The encoding is the same as the HTTP client's, and an adapter test pins that.
• Drop to fit: if the body is over 9.5 MB, qf drops inline attachments, largest first, until it fits. Non-images go first; images are dropped only if their upload failed and they are still inline. Each drop is named in a warning (attachment, size, case), followed by a summary line.
• Fail early: if the results alone are too large, qf fails with a clear message before sending, instead of getting a 413.

The parsers' own budgets are unchanged; this is the final net, in one place, for every parser. A small launch is sent byte-identically. Dry runs are unaffected, since they never offload images.

Tests: TestBodyLimit_* covers drop order, a small launch staying untouched, results alone over the limit, and dry runs, plus the adapter test that pins the wire encoding.

Known follow-ups from review (minor): the "results too large" error is raised after video and screenshot uploads rather than before them; and drop warnings still print on that error path.