[EMPSRE-1029] Add options.storage for pre-disk content validation

[dwinrick-lever]

Summary

Adds a multer-1.x-style StorageEngine hook so consumers can take over how each file part is persisted — buffer the first few KB, run a magic-byte gate, then either pipe the rest to disk or destroy the part stream. No `fs.createWriteStream` is opened until validation passes.

This unblocks the postings2 side of EMPSRE-1029 (the hook-receiver side landed in lever/hook-receiver#842 via multer's native StorageEngine). postings2 uses connect-multiparty globally; with this option it can apply the same magic-byte gate that hook-receiver does, without an upstream multer migration.

Behavior

Without `options.storage` (default): identical to current behavior. multiparty's `autoFiles=true` shortcut opens the write stream and pipes to `uploadDir`; we emit `'file'` and populate `req.files`. Fully backward-compatible.

With `options.storage`:

• `autoFields` stays on; text fields still come through as `'field'` events.
• `autoFiles` is forced off; multiparty emits raw `'part'` events.
• For each file part, we pre-populate the same `publicFile` shape consumers expect (`fieldName`, `originalFilename`, `name`, `type`, `headers`, `size: 0`) and hand it + the part stream to the storage callback.
• The storage engine is expected to fill `publicFile.path` and `publicFile.size` before calling `cb(null)`, or destroy the part stream and call `cb(err)` on rejection.

```js
app.use(multipart({
uploadDir: '/tmp',
storage: function (req, part, publicFile, cb) {
// buffer first ~4 KB → validate → pipe to disk or destroy(part)
}
}))
```

Why the in-flight counter

multiparty's `'close'` event fires when every part STREAM has ended, but the storage engine may still be flushing bytes to disk (writeStream finish, S3 upload, etc.) after that. Without tracking pending storage callbacks, `next()` could fire before `publicFile.size` is final. The wrapper now waits for every storage `cb()` to resolve before finalizing.

Test plan

• `npm test` — 16/16 pass (13 existing + 3 new):
  • storage engine receives the part stream and the prepopulated publicFile
  • storage error → 400 via existing form 'error' handler
  • async storage that completes after multiparty's 'close' is awaited correctly
• Consumer-side smoke in postings2 once we bump the pin and wire it up

[aerweb]

@dwinrick-lever LGTM. However, Claude flagged one small thing.

In storage mode, the part stream has no 'error' listener. When a request aborts mid-part,
  multiparty emits 'error' directly on the part (handleError → errorEventQueue → emit('error'),
   index.js:210-211, 644-646). The default path is safe because handleFile attaches
  fileStream.on('error') (index.js:696), but handlePart and the wrapper attach nothing — so an
  everyday client disconnect could surface as an unhandled 'error' and crash the process (and 2
   of the 3 new tests don't add a part.on('error'), so the "obvious" engine omits it too).

[aerweb]

lgtm