fix: allow a field value exactly at the fieldSize limit - #1481

A text field whose value is exactly limits.fieldSize bytes is rejected with LIMIT_FIELD_VALUE. Every other limit in multer is inclusive: fileSize, parts, files, fields and fieldNameSize all accept a request sitting exactly on the limit. Set limits: { fieldSize: 5 }, send the 5 byte value hello, and you get err.code === 'LIMIT_FIELD_VALUE' with err.field === 'field0', while hell goes through. Busboy also defaults fieldSize to a finite 1MB, so multer().none() with no limits rejects exactly 1048576 bytes, against README.md:307, "Max field value size (in bytes) | 1MB".

Busboy marks a field part truncated as soon as the value reaches the limit, at node_modules/busboy/lib/types/multipart.js:502, where fieldSize === fieldSizeLimit sets partTruncated = true. Multer turns the resulting valueTruncated straight into an error at lib/make-middleware.js:262. It already compensates for this busboy convention in the block at lib/make-middleware.js:92 to 113, but only for two of the three limits: line 107 passes limits.fileSize + 1, line 111 passes limits.parts + 1, and fieldSize is never adjusted. Those two came in with fix: allow files at exact fileSize limit and fix: allow exactly limits.parts parts. Busboy's finite default sits at multipart.js:251.

The change gives fieldSize the same treatment. busboyLimits is now built unconditionally from the caller's limits, and fieldSize goes to busboy one higher, so truncation is reported only once the limit is genuinely exceeded. That adjustment runs even with no caller limits, so a new DEFAULT_FIELD_SIZE constant pins busboy's 1MB in multer rather than inheriting it; if busboy changes its default, multer's effective limit no longer tracks it. I checked the edge cases by running them: Infinity passes through untouched and a 3MB value is accepted, 0 accepts an empty value and rejects one byte, and null falls back to the same 1MB busboy uses.

Verification on Node 22.23.2, macOS 26.2. With only the four new tests applied to unmodified main, npx mocha --reporter spec --exit --check-leaks test/error-handling.js --grep "fieldSize" gives 2 passing and 2 failing, both AssertionError: ifError got unwanted exception: Field value too long; with the lib change all four pass. The full suite goes from 165 passing to 169 passing, 2 pending and 0 failing either way, and npm run lint is clean. The third and fourth tests post 1048576 and 1048577 bytes through multer().none(), the true zero-options default, which the explicit fieldSize: 5 tests cannot reach. The fourth also passes on main, so it pins the default rather than regressing.