fix(uploads): HEIC upload 500 — pass iterable Buffer to heic-convert (#135 never worked)

[tx-joshg]

What & why

End-to-end testing of the staff-portal I-9 flow surfaced a launch-blocking bug: submitting an I-9 with a HEIC document photo fails with

List C document forward failed: open-i9 upload 500: {"error":"Found non-callable @@iterator"}

/api/uploads forwarded await file.arrayBuffer() — a raw ArrayBuffer — to heic-convert. Internally heic-decode's isHeic() does:

String.fromCharCode(...array.slice(8, 12))   // spreads the input

Spread requires an iterable. A Buffer/Uint8Array is iterable; a raw ArrayBuffer is not, so it throws Found non-callable @@iterator (older V8) / Spread syntax requires ...iterable[Symbol.iterator] to be a function (newer V8) and the upload 500s.

It only triggers on the HEIC/HEIF path, so non-HEIC docs (e.g. a JPEG license) worked — which is why the HEIC support added in #16 (#135) never actually worked on a real iPhone photo.

Contributing cause: @types/heic-convert mistypes buffer as ArrayBufferLike, which is what lured the route into passing a raw ArrayBuffer (type-checks, crashes at runtime).

Fix

• New src/lib/heic.ts → heicToJpeg(input) normalizes Buffer | Uint8Array | ArrayBuffer to an iterable Buffer before calling heic-convert (and casts past the incorrect d.ts).
• /api/uploads calls the helper.

Tests

Adds node:test (run via tsx, npm test) + a real ~1KB HEIC fixture made with sips. Covers Buffer, ArrayBuffer (the exact regression), and Uint8Array inputs — all must yield a JPEG.

✔ heicToJpeg converts a real HEIC Buffer to a JPEG
✔ heicToJpeg accepts a raw ArrayBuffer (PR #16 regression)
✔ heicToJpeg accepts a Uint8Array view

Verified: tsc --noEmit clean (0 errors), next lint clean, reproduced the original failure and confirmed the fix end-to-end (real HEIC → valid JPEG).

Deploy note

No staff-portal change needed — it correctly forwards the HEIC. After this deploys, re-run the I-9 submit to confirm.