[yeelam-gordon]

This PR contains the non-Arm64-specific compatibility fixes that were previously bundled into #1089 while validating the Windows Arm64 CLANGARM64 toolchain.

Scope in this PR:

• FFmpeg 9 / libavcodec 62 API compatibility and spherical metadata behavior
• OpenCV 5 header/API compatibility
• ImageMagick 7 buffer/lifetime fixes
• Windows/runtime test portability fixes
• Ninja/CMake test-target compatibility fixes

This is a prerequisite split so that #1089 can stay narrow and Arm64-specific (CI lanes, package lock, architecture validator, and native-process oracle coverage).

[github-actions]

Merge conflicts have been detected on this PR, please resolve.

[jonoomph]

Thanks for separating these compatibility fixes! Two concerns currently block this: TrackedObjectBBox.cpp is always built, but its protobuf generation/linking is still OpenCV-only; and the spherical tests expect zero angles on every FFmpeg version, dropping nonzero round-trip coverage. We need to preserve OpenCV-disabled builds and angle checks where supported. This also needs a rebase and coordination with #1088 to avoid duplicate capability implementations.

[jonoomph]

Thanks again for this work! While testing newer FFmpeg compatibility on our arm64-support integration branch, we investigated the spherical-metadata failures and found two separate issues:

• Writer metadata loss: the existing spherical tests fail with missing metadata on FFmpeg 7.0, 7.1.3, and 8.0. Encoder initialization copies parameters into codecpar, replacing the spherical side data attached earlier. On 7.1.3, experimentally attaching it to the encoder context instead preserved the metadata without changing the writer’s initialization sequence.
• FFmpeg reader behavior: after that fix, projection metadata survived, but orientation angles came back as zero. In FFmpeg 7.1.3, mov_read_vexu_proj() allocates a new spherical mapping, replacing the mapping populated from sv3d and losing its angles. The same code is present in 8.0. This appears to be a demuxer issue, rather than proof that the writer cannot store the angles.

Please preserve the nonzero-angle assertions where supported. They pass with our older FFmpeg 4.2.x build. For affected versions, we should separately verify the angles written into the MP4 and account for the reader defect, rather than expect zero on every version.

We’re keeping the spherical changes separate while investigating this. The earlier OpenCV-disabled build concerns also remain outstanding.