REST API: Apply unapplied EXIF orientation before image edits

[ramonopoly]

This ticket tracks the backport of ​https://github.com/WordPress/gutenberg/pull/80144

## What

Fixes image edits (rotate, crop, flip) landing in the wrong frame for photos whose EXIF orientation tag was never applied to their pixels, most visibly iPhone JPEGs. Rotating such a photo in the media editor modal or the Image block cropper previously appeared to do nothing.

## Why

The /wp/v2/media/{id}/edit endpoint edits the file from wp_get_original_image_path(). That original often still carries an unapplied EXIF orientation tag: client-side uploads preserve it deliberately, and server-side uploads only bake the rotation into the scaled copy, never the original.

Browsers apply the tag when rendering, so clients build their edit modifiers against the upright preview while the server applies them to the raw, unrotated pixels.

For an orientation 6 photo, a 90° rotation request produced pixels identical to what the user was already seeing, so the edit looked like a no-op. Crops had the same frame mismatch

See ​Gutenberg conversation #77582 (comment)

Thank you for trying this out! I haven't gotten to review this properly yet as I wanted to get to the bottom of the other EXIF rotation bug we ran into. I have a tentative fix for it over in ​https://github.com/WordPress/gutenberg/pull/80295... I don't _think_ it'll wind up causing any differences for this PR, but just linking to it as it's thematically linked (trying to make sure we handle EXIF rotation correctly).

Just retested this:

### Trunk

​https://github.com/user-attachments/assets/a1561875-6098-47d9-b3e1-c2559acab47c

### With this PR

​https://github.com/user-attachments/assets/6204fba4-5d6a-47d2-90d9-dec459d598b5

What do folks think, would be an okay inclusion in 7.1?

This is testing nicely for me, and crops of EXIF rotated images appear to be working nicely now where they weren't before. And it's a no-op for files that didn't have any rotation applied 👍

Thanks for testing, I'm in favor of getting this in for 7.1 during the beta cycle.

Thanks folks!

[ramonopoly]

In 62820:

Attachments REST API: Apply unapplied EXIF orientation before image edits

Fixes image edits (rotate, crop, flip) landing in the wrong frame for photos whose EXIF orientation tag was never applied to their pixels, most visibly iPhone JPEGs. Rotating such a photo in the media editor modal or the Image block cropper previously appeared to do nothing.

WP_REST_Attachments_Controller::edit_media_item() edits the image from wp_get_original_image_path(). That original image often still carries an unapplied EXIF orientation tag.

WP_REST_Attachments_Controller::edit_media_item() now calls $image_editor->maybe_exif_rotate() before modifying the image for cropping.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/12492(​https://github.com/WordPress/wordpress-develop/pull/12492)

Props ramonopoly, andrewserong, adamsilverstein.

Fixes #65618.

Committed in r62820](https://core.trac.wordpress.org/changeset/62820) / 984563262deb77d6dac1d5f7e94ca7dc405815c2