fix: normalize image orientation before conversion

[yeagoo]

Converting a TIFF or EXIF-oriented JPEG to an output without its orientation tag can rotate or mirror the displayed result incorrectly. For example, a 48 × 32 TIFF with orientation 6 becomes a sideways 48 × 32 WebP instead of a normalized 32 × 48 image.

Call autoOrient() while the orientation information is still present, before the existing ICO resize and metadata removal. Normalize with either metadata setting so viewers do not apply the rotation twice.

Validation

All eight orientations (including mirrored variants) are checked through PNG and WebP encoding with metadata both retained and removed. A JPEG fixture also verifies that EXIF/XMP/comments can be removed after the pixel orientation is applied.

• bun run test: 8 passed, including five shared behavior tests.
• The defect-focused tests fail against the unchanged upstream conversion function (3 failing tests before this fix).
• bun run build: passed with a local .env based on .env.example.
• ESLint and Prettier: changed files pass.
• bun run check: the same 7 pre-existing missing Node type errors as upstream; no additional errors. Full-repository lint has existing failures outside this change; changed files pass.

Patch structure

This branch is based on upstream cc7b5a54d5e9c797b377db47b9bdfbb561707783 and includes shared test harness commit c69e961, which moves the existing magickConvert function unchanged into a utility imported by the worker. Tests invoke that exact production function with the installed WASM. No new package dependency is introduced.

Each repair branch can be reviewed independently. After the shared harness lands, the remaining branches will need rebasing onto upstream main to resolve overlapping edits in magick-convert.ts.

[JovannMC]

note: this is a boilerplate response for numerous open PRs

hiya!

firstly sorry for the late response to your PR (if it has been open for a while). we are closing this, along with other people's PRs, as we are preparing for the very overdue update drop. once merged, it will most likely break most existing PRs and will need to be redone. track the PR #282, and once merged you may wish to open another PR with the new base.

do also note this repository's and our main contributing guidelines which was made recently here, when submitting your new PR: repo & main