Media: Allow HEIC/HEIF sequence uploads when the server lacks editor support

[adamsilverstein]

Trac ticket: https://core.trac.wordpress.org/ticket/65873

What

Extends the HEIC/HEIF upload bypass added in #64915 to the multi-frame -sequence variants: image/heic-sequence and image/heif-sequence, which is what Apple Live Photos and Android bursts are.

Today those are rejected with rest_upload_image_type_not_supported when the server's image editor cannot handle them, which is most servers.

Why

The original exclusion was correct when it was written - the comment says the sequence variants are skipped because "neither the server nor the browser fallback can process them yet". The browser half of that has changed: WordPress/gutenberg#79647 demuxes a sequence and decodes its first frame in the browser, uploading that still in its place, so a capable browser never reaches this check at all.

More to the point, rejecting them is inconsistent with what the rest of the pipeline does with the same bytes. wp_check_filetype_and_ext() renames a .heics upload to .heic and rewrites its type to image/heic, verified against a real 120-frame sequence:

wp_get_image_mime()        => 'image/heif-sequence'
wp_check_filetype_and_ext():
  ext                      => 'heic'
  type                     => 'image/heic'
  proper_filename          => 'live-photo.heic'

So a file this permissions check turns away is one the very next step would have relabelled as an ordinary still HEIC - a mime type the same check already allows. The bytes are stored unchanged either way; only the label differs.

Approach

Uses the existing wp_is_heic_image_mime_type() helper, which already returns true for all four mime types, in place of the hardcoded still-only array. This is what #64915 originally proposed before it was narrowed. Net 7 lines removed from the source.

Testing instructions

1. Ensure the server has no image editor that supports HEIC: add_filter( 'wp_image_editors', '__return_empty_array' );
2. Upload a .heics file (or any file sent as image/heic-sequence) through POST /wp/v2/media.
3. Before this change the request fails with rest_upload_image_type_not_supported; after it, the attachment is created.

The existing unit test asserting the old behavior is removed, and the sequence mime types are folded into the data provider for the bypass test so one case covers all four:

phpunit --filter test_upload_heic_bypasses_unsupported_image_type_check

AI Use

Claude Code wrote this patch and the description. I will review and test.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.