fix: refuse HEIC plane copy when decode size mismatches handle (#14)

[nonamexishere]

Summary

Addresses #14: HEIC/HEIF import can ACCESS_VIOLATE on real phone photos after #29 and #49.

After heif_decode_image, OffPDF now inspects the decoded interleaved plane (width/height/chroma/bpp) and refuses to copy if it does not match the handle-sized output buffer. copy_pixels sizes rows from the plane. Decode requests 8-bit conversion when options can be allocated.

This branch is from development only. It does not include #54 or #55.

In scope

• Remaining handle-vs-plane copy unsoundness (grid / irot stand-ins)
• Invalid/truncated/oversized files still return AppError
• Synthetic HEIC/HEIF still convert to a one-page PDF
• RGBA 32-bpp-like fixture convert-or-INVALID_IMAGE

Out of scope

• Claiming the Windows tester’s two private device files are fixed (needs packaged smoke)
• Edit PDF overlay, test(editor): validate and round-trip edited PDF outputs before publish #34 gate, feat(editor): add, edit and remove PDF link annotations #35 links

Why

#49 validated stride and dest length using handle dimensions. A shorter or swapped plane can still pass stride >= row and then read off the buffer (0xc0000005 on Windows).

Validation

• npm run typecheck
• npm test (179)
• cargo test --manifest-path src-tauri/Cargo.toml --lib (97)
• cargo test -p heif-rs --manifest-path src-tauri/Cargo.toml --lib
• Manual macOS HEIC/HEIF import, garbage, truncated, and batch (app stayed up)

Privacy Checklist

• This keeps OffPDF usable offline.
• This does not upload, log, or transmit user files.
• New dependencies or bundled binaries have compatible licenses.