feat(processing): reactive FIFO processing pipeline and worker-thread PDF merge

[manuc66]

Problem

While a scan is post-processed (PDF merge, uploads), the listen and adf-autoscan loops await the whole delivery before polling the printer again. A slow destination or a heavy merge can make the loop miss the next scan event or trip the printer's userActionTimeout / waitScanNewPageRequest timeouts. In single-scan this is one iteration and does not matter.

Solution

Producer/consumer in the same process:

• Explicit staged pipeline (postProcessing): generate PDF → announce → deliver → cleanup, threaded through a shared context — the seam where future pre-processing stages (OCR, --post-command) plug in.
• FIFO processing queue (src/queue/processingQueue.ts): captured scans are drained in capture order by one background worker; the loop returns to polling immediately.
• PDF merge off the event loop (src/pdfMergeWorker.ts): jsPDF runs in a worker thread, so health checks and printer HTTP responses stay responsive during a big merge.
• single-scan keeps its synchronous contract (exits only once delivery finished), routed through processScanProcessingJob.

Durability (explicitly not part of this PR)

The queue is in memory. A crash mid-job leaves captured files on disk (cleanup only runs once delivery finished) and delivery can be redone by hand — no worse than the previous synchronous behavior, and no breaking change for existing Paperless/Nextcloud users.

Review checklist

• Durability trade-off: the queue is in memory — a crash mid-job leaves captured files on disk and delivery can be redone by hand. Confirm this is acceptable and documented before merging (a conditional durable inbox is planned as a follow-up).
• Memory (partial): the PDF merge is off the event loop (worker thread). The remaining whole-file fs.readFile reads (webhook sha256, S3 upload) belong to the S3/webhook PRs.
• Non-blocking delivery: webhook/upload sending no longer blocks the scan loop — delivery runs on the background drain. Verify with the real-services harness.
• Error isolation: outbox/write errors are confined to the drain worker and no longer increment the listener's anti-crash errorCount. Verify the listener keeps running when a delivery target is unreachable.
• Startup: the startup flushOutbox blocking is the webhook PR's concern; here the queue guarantees the scan loop is never blocked by a slow delivery.

Merge this PR first — it is the foundation. The S3-delivery and webhook/outbox PRs follow.

Testing

• test/processingQueue.test.ts: enqueue returns before the work completes (capture not blocked), FIFO order through a real delivery, awaited single-job path.
• Full suite green (674 passing) including the adapted listenCmd/postProcessing suites.