Hardware Decoding Deadlock on Apple Silicon When Mixing Mislabeled ProRes Proxy (4:4:4) and ProRes 4444 Clips of Identical Resolution

ISSUE
With hardware-accelerated decoding enabled, Premiere Pro on Apple silicon stops returning frames when a sequence contains (a) a QuickTime file tagged as ProRes 422 Proxy ('apco') whose frames are actually encoded 4:4:4, and (b) a genuine ProRes 4444 ('ap4h') clip of the exact same frame size. Whichever of the two clips is decoded first plays; the other never displays, and the first then also fails after scrubbing back. Each file plays normally on its own. The mislabeled files come from ffmpeg's prores_ks encoder ("-profile:v 0" without "-pix_fmt yuv422p10le"), which is common in EPK and vendor deliverables.

STEPS TO REPRODUCE
1. Preferences > Media: enable hardware accelerated decoding. Restart Premiere Pro.
2. Open the attached project REPRO_1_BAD_Proxy_then_4444.prproj and relink the two attached clips if prompted:
   - SYNTH_A_BAD_Proxy_tagged_but_444_1080x1920.mov: FourCC 'apco' (ProRes 422 Proxy), but frames are 4:4:4 10-bit (frame header chroma_format = 3). 1080x1920, 24p, Rec.709. Made with: ffmpeg -f lavfi -i testsrc2=size=1080x1920:rate=24 -c:v prores_ks -profile:v 0 -pix_fmt yuv444p10le
   - SYNTH_B_ProRes4444_1080x1920.mov: genuine ProRes 4444 ('ap4h'), 1080x1920, 24p, Rec.709.
3. In the sequence REPRO_1_BAD_Proxy_then_4444 (V1: the bad Proxy clip, a ~1 s gap, then the 4444 clip), press Play from the start.
4. Let the playhead cross into the 4444 clip, then scrub back over the first clip.

EXPECTED RESULT
Both clips play back and scrub normally.

ACTUAL RESULT
The first clip plays. When the playhead reaches the 4444 clip, the Program Monitor stops updating and no frames are returned. Playback and scrubbing stay stalled on that clip. If the clip order is reversed, the 4444 clip plays and the bad Proxy clip stalls instead, and scrubbing back to the first clip then fails too. Disabling hardware decoding fixes it immediately.

Process samples taken during the stall (attached) show up to 15 decode threads blocked in:
  ImporterQuickTime::IFrameDecodeRequest::DoCPUProcessing > CodecSupport::ProResDecompressor::DecompressPixelsAsync > QT64Utils::DecompressProResFrame > dvacore::threads::WaitableGate::PassThroughUntil
and the player thread (ML::PlayModuleThreadQueue) blocked on a mutex in:
  SWHostRenderClipPrefetch::SelectBestFrameFormat > ML::VideoImporterStream::SelectBestFrameFormat > ML::ImporterInstance::CreateUnquieter > ML::ImporterInstance::UnquietPeriodBegin
No thread is doing decode work or file I/O during the stall.

Isolation (all with hardware decoding on):
- Control project REPRO_2_CONTROL_good_Proxy_then_4444.prproj, a genuine 4:2:2 ProRes Proxy next to the same 4444 clip: plays correctly.
- The real-world mislabeled file re-encoded as true 4:2:2 Proxy: plays correctly.
- The same mislabeled file with only its FourCC changed from 'apco' to 'ap4h' (2-byte header edit, frames unchanged): plays correctly. So the mismatch between label and frames is the trigger.
- 4444 at a different frame size (1088x1920 or 1920x1080) next to the mislabeled 1080x1920 file: plays correctly. Only an identical frame size reproduces it.
- ProRes 422 HQ at the same size next to the mislabeled file: plays correctly.
- Reproduces with 4444 files from both After Effects 2024 and ffmpeg.
- Reproduces with media on local SSD and on 25GbE NAS storage.
- Hardware decoding off: no issue in any case.

The mislabeled file is malformed (ProRes 422 Proxy is defined as 4:2:2 only), but Premiere should either decode it or fall back to software decoding rather than stalling playback indefinitely. QuickTime Player and the software decode path both handle it.

PREMIERE VERSION
Premiere Pro 26.5.2 (build 26.5.2.5). Also reproduced on 26.3.2.

OPERATING SYSTEM
macOS 26.7.1 (25G241)

CHIP (MAC)
Reproduced on two machines:
- Apple M4 Max Mac Studio, 64 GB RAM, 1 TB SSD, ATTO ThunderLink TLNS3252 (25GbE, latest ATTO driver)
- Apple M4 Pro Mac

VIDEO FORMAT
QuickTime .mov. ProRes 422 Proxy-tagged ('apco') file with 4:4:4 10-bit frames (encoder: Lavc/ffmpeg prores_ks), 1080x1920, 24 fps, Rec.709, with or without 16-bit PCM stereo audio. Paired with ProRes 4444 ('ap4h') 1080x1920, 24 fps, no alpha. Sample files attached (synthetic test patterns, no customer media).

PROJECT SIZE
Repro project: 2 clips in 1 sequence, about 11 KB, not a Production.
Original production project where we found it: about 900 KB on disk (about 12 MB uncompressed), 27 sequences, about 440 clip items, 80 media files, not a Production.

HELPFUL CONTEXT
- Does it affect all projects or only some? Only projects where a mislabeled 'apco'-with-4:4:4 file and a ProRes 4444 file of the same frame size are used together.
- Does it affect new, empty projects? Yes. The attached two-clip repro is a brand-new project.
- When did the problem first begin? 9 Oct 2026, when an EPK batch encoded with ffmpeg (Lavf 62.12.102 / Lavc 62.28.102 prores_ks) was added to a project that already contained ProRes 4444 graphics at the same 1080x1920 size.

ATTACHMENTS
REPRO_1_BAD_Proxy_then_4444.prproj, REPRO_2_CONTROL_good_Proxy_then_4444.prproj, SYNTH_A_BAD_Proxy_tagged_but_444_1080x1920.mov, SYNTH_A_ProResProxy_1080x1920.mov, SYNTH_B_ProRes4444_1080x1920.mov, two process samples (Sample_1_Premiere_original_4444_stall.txt, Sample_2_Premiere_COLRFIX_stall.txt), screen recording.