Support Windows ARM64 libmpv

[NihilDigit]

Summary

This PR is part of the work to add Windows on ARM packaging support for Kazumi (Predidit/Kazumi#1008).

It adds Windows ARM64 support to media_kit_libs_windows_video. When CMake targets ARM64, the package now uses the aarch64 libmpv archive. Other Windows builds keep using the existing x64 archive and extraction path.

Changes

• Detect Windows ARM64 from CMAKE_SYSTEM_PROCESSOR and CMAKE_GENERATOR_PLATFORM.
• Use mpv-dev-aarch64-20251210-git-ad59ff1.7z for ARM64 builds.
• Keep mpv-dev-x86_64-20251210-git-ad59ff1.7z unchanged for x64 builds.
• Use 7-Zip to extract the ARM64 archive.
• Add a Windows ARM64 CI job that builds media_kit_test on windows-11-arm.

The x64 archive still uses the existing CMake extraction path. 7-Zip is only used for the ARM64 archive because CMake's built-in extractor fails on that .7z file on Windows ARM64:

Unexpected codec ID: a

Validation

I validated this by pinning Kazumi to this media-kit commit in a fork and running the Windows ARM64 build there.

• flutter build windows completed on GitHub's Windows ARM64 runner.
• The build produced an ARM64 Windows zip package.
• The package was tested locally on a Windows on ARM machine.

Validation run:
https://github.com/NihilDigit/Kazumi/actions/runs/27873267299

This PR also adds a native Windows ARM64 CI build for media_kit_test.

[Predidit]

7zip 直接依赖外部符合预期吗，虽然在 runner中没有问题，但这并不是 Windows11 会预装的组件。

[NihilDigit]

7zip 直接依赖外部符合预期吗，虽然在 runner中没有问题，但这并不是 Windows11 会预装的组件。

上游的 libmpv-win32-video-cmake 打出来的7z包用CMake解不开，可能CMake在ARM上的解压能力不完整，如果到上游打.zip也可以解决。

[Predidit]

这个修复更合理，不过你会倾向哪种解决方案，由于 Windows Arm 用户及其有限，在我看来此pr按照原样合并，或者我们现在重新磕libmpv构建工作流都是可以的。

上一次构建已经过去半年，由于依赖变化，应该无法直接发布新构建，libmpv发布会需要一些修复。

[NihilDigit]

这个修复更合理，不过你会倾向哪种解决方案，由于 Windows Arm 用户及其有限，在我看来此pr按照原样合并，或者我们现在重新磕libmpv构建工作流都是可以的。

上一次构建已经过去半年，由于依赖变化，应该无法直接发布新构建，libmpv发布会需要一些修复。

我比较倾向暂时用 7z 做workaround，Windows on ARM这种小众平台上的工具链不是非常稳定和成熟，做到完美流程的投入产出比可能不高。

[CanghaiDragon]

这个修复更合理，不过你会倾向哪种解决方案，由于 Windows Arm 用户及其有限，在我看来此pr按照原样合并，或者我们现在重新磕libmpv构建工作流都是可以的。

上一次构建已经过去半年，由于依赖变化，应该无法直接发布新构建，libmpv发布会需要一些修复。

开发者您好，我看您在2.1.7的日志提到增加了对Windows arm64的支持，但我查看任务管理器后发现不管是msix还是zip均运行的是x64的程序，只有在本分支下的2.1.6版本有arm64版本，所以目前2.1.7还没有正式支持arm吗？不管怎么说首先感谢您们愿意适配arm64，希望能尽快同步到正式release里

[NihilDigit]

这个修复更合理，不过你会倾向哪种解决方案，由于 Windows Arm 用户及其有限，在我看来此pr按照原样合并，或者我们现在重新磕libmpv构建工作流都是可以的。
上一次构建已经过去半年，由于依赖变化，应该无法直接发布新构建，libmpv发布会需要一些修复。

开发者您好，我看您在2.1.7的日志提到增加了对Windows arm64的支持，但我查看任务管理器后发现不管是msix还是zip均运行的是x64的程序，只有在本分支下的2.1.6版本有arm64版本，所以目前2.1.7还没有正式支持arm吗？不管怎么说首先感谢您们愿意适配arm64，希望能尽快同步到正式release里

https://github.com/NihilDigit/Kazumi/actions/runs/27873267299/artifacts/7765942435 可以尝试用这个测试构建，不过由于缺失相关key，弹幕功能不能使用。Kazumi短期内可能不会对woa64完整支持，不过 Predidit/Kazumi#2259 这个PR基本上是跑通的，可以尝试自行fork并编译，配置好secrets之后重跑CI弹幕功能应该会恢复。