feat(scan): compress phone-photo receipts before upload (browser-image-compression)

Phase 3 — wires `browser-image-compression` into the scan-shell so 4-12 MB
phone photos get crushed to ~500 KB in a WebWorker before any other work
happens. Receipts come back from tesseract + the AI parse much faster on
mobile bandwidth, and the server's sharp pipeline has less to chew on.

compressReceiptIfHeavy(file):
  - Pass-through for SVGs / PDFs / non-images
  - Pass-through for files already under 1 MB
  - Otherwise: imageCompression with maxSizeMB: 0.5, maxWidthOrHeight:
    2000, useWebWorker: true, preserveExif: false (auto-rotate to EXIF
    orientation then strip metadata so the receipt isn't sideways)
  - PNG → JPEG transcode (smaller for natural photo content)
  - Initial quality 0.85 — Tesseract's sweet spot for receipt text
  - Lazy-loaded import: the WebWorker bundle isn't on the critical path
  - try/catch fallback: if compression itself throws, fall through to
    the original file so a corner-case bug never blocks a save

Wired into handleFile(rawFile) before tesseract runs and before the
receipt is sent to /api/v1/expenses/scan-receipt. Downstream upload
through handleSubmit() also benefits because the same compressed File
flows through.

Concrete impact for a 12 MP iPhone receipt (~8 MB):
  Before: 8 MB upload, 8 MB tesseract input
  After:  ~500 KB upload, 2000px max edge tesseract input

Bandwidth + battery + perceived latency win on the mobile expense
scanner path. No behaviour change for desktop file uploads under 1 MB.

1298/1298 vitest green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

package.json

@@ -64,6 +64,7 @@
     "@types/pdfkit": "^0.17.6",
     "archiver": "^7.0.1",
     "better-auth": "^1.6.10",
+    "browser-image-compression": "^2.0.2",
     "bullmq": "^5.76.8",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",