feat(ohos): support native assets builds

[tignioj]

问题与结果

Flutter-OH 当前通过 Linux target 向 Native Assets hook 传入 OHOS 构建参数。现有 hook 会选择 Linux 原生库及编译目标，导致新版 media-kit 的 OHOS 构建无法正确完成。本 PR 补齐 OHOS arm64 的原生库打包和事件循环桥接，复用仓库已有的鸿蒙 libmpv 与 ArkTS 纹理渲染实现。

改动

• 通过 Flutter-OH 提供的编译器 SDK 识别 OHOS，也支持显式 target: ohos 和 SDK 配置；仅设置 OHOS 环境变量不会把普通 Linux 构建识别成 OHOS。
• 将 OHOS bundle 的主库名修正为实际归档及 SONAME 使用的 libmpv.so，并在 bundle 缺少时补充 SDK 的 libc++_shared.so。
• 使用 OHOS target triple 和 sysroot 编译 C 事件循环桥接，注册对应 Native Assets；对尚无预构建库的 OHOS 架构明确报错。
• 放宽构建依赖的下限以兼容 Flutter-OH 3.41 固定的 meta 1.17，同时保留较新版本的可选范围：code_assets >=1.2.1 <3.0.0、hooks >=2.0.2 <3.0.0、native_toolchain_c >=0.19.1 <0.20.0。这不是强制降级依赖。
• 增加 OHOS 目标识别及 bundle 配置测试，并补充接入与验证说明。

验证

• 本地 hook/core 测试 20 项全部通过（dart test test/hook test/src/player/native/core/native_library_test.dart test/src/player/native/core/native_property_test.dart --reporter expanded）。该次解析版本为 code_assets 2.1.0、hooks 2.2.0、native_toolchain_c 0.19.5。
• dart analyze hook test/hook 无问题；修改的 Dart 文件格式检查通过，git diff --check 通过。
• Kazumi 使用 Flutter-OH 3.41.9+ohos-1.0.2 / Dart 3.11.5 完成 Debug 与 Release AOT 构建。集成项目解析版本为 code_assets 1.2.1、hooks 2.0.2、native_toolchain_c 0.19.2、meta 1.17.0。
• MatePad mini（HarmonyOS API 26，arm64）真机验证软解及 ohcodec 硬解、同步及异步播放器模式、纹理画面显示，以及重复/并发销毁。Release 两轮共通过 24 次播放/销毁和 6 次初始化期间销毁，最终 native handle 归零。
• Kazumi 集成与真机验证说明。

当前 OHOS 验证范围为 arm64 真机，未覆盖模拟器及其他架构。本地未重新执行完整多平台构建矩阵，其他平台回归仍需由仓库现有 CI 确认。

[Predidit]

有一个小问题，我们为什么为 code_asserts 之类的依赖项添加了版本上限

在正常情况下，如果 sdk 或是其他依赖不支持高版本，我们应该会自动使用较低版本

[tignioj]

感谢指出，Pub 会根据 SDK 和其他依赖的约束自动选择兼容版本，这点是对的。

这里其实没有新增上限：原来的 code_assets: ^2.1.0 就等价于 >=2.1.0 <3.0.0；hooks: ^2.2.0 和 native_toolchain_c: ^0.19.5 也已经分别包含 <3.0.0 和 <0.20.0 的上限。

本次主要是降低下限，让 Flutter-OH 固定 meta 1.17 时能够自动选到兼容的旧版本。原来的下限排除了这些版本，因此 Pub 无法自动回退。

保留原有上限是考虑未来可能出现的破坏性 API 变更；即使 SDK 和依赖约束满足，Pub 也无法判断我们的代码是否兼容新版 API。PR 中显式写出范围，容易让人以为额外增加了限制，这里说明一下。

[Predidit]

如果我的理解没有问题，当前这个稍微有些 hack 的实现更多依赖鸿蒙工具链的特定行为而不是 flutter/dart 工具链行为，如果出现破坏性变更，其他平台一样大概率会被破坏，在这种情况下我们为什么仍然要添加上限

[tignioj]

如果我的理解没有问题，当前这个稍微有些 hack 的实现更多依赖鸿蒙工具链的特定行为而不是 flutter/dart 工具链行为，如果出现破坏性变更，其他平台一样大概率会被破坏，在这种情况下我们为什么仍然要添加上限

原来的写法 ^2.1.0 也有上限的。准确来说这个上限在我PR之前，就已经加上去了。 https://dart.dev/tools/pub/dependencies#caret-syntax
而我的写法：'>=1.2.1 <3.0.0' 实际上只是降低了下限，如果不加上限的话，比如只是写成>=1.2.1, 会允许 3.x、4.x，反而扩大了你原本写法的范围。

[Predidit]

我原来从未指定上限，关于上限的约束即使存在，也是相关工具链的内部细节，不需要我们关注，但是此PR将其显式化了

[tignioj]

我原来从未指定上限，关于上限的约束即使存在，也是相关工具链的内部细节，不需要我们关注，但是此PR将其显式化了

那可能是我对Dart文档的依赖写法的理解有偏差。

我可以将 hooks 和 native_toolchain_c 分别改为 ^2.0.2、^0.19.1，沿用原来的声明风格。
code_assets 稍有不同：这里需要同时支持已验证的 1.x 和 2.x，单写 ^1.2.1 会排除 2.x，因此此前使用了区间写法。如果这里也希望取消显式上限，我可以改为 >=1.2.1，将未来大版本的兼容性交由后续升级验证。

[Predidit]

感谢你的指正，我之前没有关注过类似问题，我已经理解这里的跨版本兼容问题了