fix: do not end parts() iteration while busboy still holds undelivered parts

[mcollina]

Summary

Fixes #630.

request.on('close') fires once the message body has fully drained into busboy's writable buffer. Busboy defers its write ack when a file stream backs up, so on a fast/re-segmented connection the request can complete while busboy still holds parsed-but-undelivered parts. The cleanup bound to close pushed the end marker into the same queue the parts flow through, and every part emitted afterwards landed behind it — trailing file parts and fields were silently lost, exactly as reported.

Changes

• End iteration on busboy's own end events. request.on('close') only terminates the iteration when the message did not complete (readableEnded === false, i.e. a client abort), and then with a new PrematureCloseError (FST_MP_PREMATURE_CLOSE, exposed via fastify.multipartErrors and the TypeScript types) instead of a silent clean end.
• Surface Unexpected end of multipart data as an error. The suppression came in mechanically with the busboy v2.1.0 upgrade (use @fastify/busboy v2.1.0 #506); it made truncated uploads indistinguishable from complete ones. A fully empty body (zero bytes received) is still treated as an empty form, preserving the behavior pinned by multipart-empty-body.test.js.
• End iteration when the consumer destroys a file stream without reading it to the end. Busboy never emits finish in that case; previously the close-based cleanup masked this, and without a guard parts() would hang forever (caught by the existing should not freeze when error is thrown during processing test).

Reproduction / tests

Written TDD-style in test/fix-630.test.js (red on main, green here):

1. Trailing parts survive early request close — slow consumer, 200 KB file + 6 KB mask + three fields. A large busboy highWaterMark makes the failing event ordering deterministic on loopback (the same ordering the issue reproduced through Docker Desktop's port forwarding with default settings); on main the handler sees only the first file.
2. Truncated multipart data rejects with Unexpected end of multipart data instead of ending cleanly.
3. Client abort mid-upload rejects the iterator — guards that dropping the close-based cleanup doesn't reintroduce hangs on aborts.

Behavioral note

Consumers that previously saw a clean-looking, silently-truncated iteration on truncated or aborted uploads now get an error — that is the point of the fix, but it may warrant a semver-major release.

Checklist

• run npm run test — 90/90 unit tests, 100 % coverage, tstyche 34/34
• tests and/or benchmarks are included
• documentation is changed or added — no doc changes needed (error is exported via existing multipartErrors mechanism)
• commit message follows commit guidelines

🤖 Generated with Claude Code

[gurgunday]

Lgtm