fix(ci): resume OpenWrt SDK downloads and stop OpenWrt failures blocking releases

[BFNOC]

问题

v2.1.26 和 v2.1.27 的 Build Release Binaries 都卡在 Install pinned OpenWrt musl toolchain，Release 和 Docker 镜像都没有发布：

v2.1.26 arm64  curl: (28) Operation timed out after 600002 milliseconds with 48234496 out of 219641311 bytes received
v2.1.26 amd64  curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
v2.1.27 arm64  curl: (18) transfer closed with 84375007 bytes remaining to read

v2.1.26 的 armv7 和 v2.1.27 的 amd64 在同一步跑满 30 分钟，被任务超时取消。v2.1.27 的 armv7 下载成功并编译完成，但因为 Release 被跳过，也没有发出来。

原因有两个：

1. 下载方式：curl --retry 3 --max-time 600 每次尝试最多 10 分钟，重试从 0 开始。downloads.openwrt.org 到 GitHub runner 经常只有不到 200 KB/s，还会中途断开，220 MB 的 SDK 一次下不完，重试几次就超过 30 分钟的任务上限。--http1.1 避开了 PROTOCOL_ERROR，但避不开断开（exit 18）和超时（exit 28）。
2. 依赖关系：release 依赖 OpenWrt 任务，docker-publish.yml 只在整个 run 成功时才推镜像，所以一个 OpenWrt 下载失败，linux 二进制明明已经编译好，Release 和 Docker 镜像也都发不出来。

修改

• fix(ci): resume OpenWrt SDK downloads across official mirrors
  • 新增 packaging/openwrt/fetch-sdk.sh，binary-release.yml 和 Dockerfile.sdk 都通过它下载 SDK
  • 先对 3 个下载源（downloads.openwrt.org、archive.openwrt.org、第三方的 ftp.halifax.rwth-aachen.de）各下载 1 MiB 测速，按速度排序；测速失败的不参与，全部失败时才都参与
  • 每次尝试用 curl -C - 接着已下载的部分继续；低于 10 KiB/s 持续 60 秒，或单次超过 240 秒，就换下一个下载源。默认最多 5 次，打包任务的 docker build 里最多 3 次，都在原有的超时之内
  • URL 只接受 https://downloads.openwrt.org/releases/*/openwrt-sdk-*.tar.zst，下载和重定向都限定 HTTPS；sha256 仍然用 sdk-matrix.json 里固定的值，脚本校验一次，解压前再校验一次
  • 每次尝试记录下载源和已有字节，失败时记录 curl 退出码、用时和前后字节，下载中每 30 秒记一次进度；sha256 不对时记录实际 hash 和文件开头，然后从 0 重下。连续两次没有进展也从 0 重下
  • build-openwrt 的 3 个 SDK 用 actions/cache 按矩阵项缓存；打包任务的 docker build 不走这层缓存
• fix(ci): publish the release and Docker image when OpenWrt builds fail
  • OpenWrt 构建和打包任务设为 continue-on-error，失败不影响整个 run 的结论
  • 部分 OpenWrt 构建失败时，打包任务照常运行，只打包成功的架构
  • 只要 linux 构建成功就发布 Release；run 结论为 success，docker-publish.yml 照原有逻辑推镜像
  • release 缺少 OpenWrt 文件时给出 warning，列出缺了哪些
  • 上传产物加 overwrite: true，重跑时不会因为同名产物报错

行为变化

• OpenWrt 的任何失败（下载、编译或打包）都不再挡住 Release 和 Docker 镜像。run 显示成功，失败的任务在 run 里显示为红色，release 任务上有 warning
• Release 和 SHA256SUMS 可能先缺少 OpenWrt 文件发布，重跑后通过原有的 overwrite_files: true 补上
• 全部成功时，发布的文件和 v2.1.25 的 binary-release 一样：linux 3 个、OpenWrt 静态和动态各 3 个（都带 sha256）、6 个打包，加 SHA256SUMS

验证

在 fork 上用 workflow_dispatch 跑的：

• 完整一轮（最终版本，版本 dev）：https://github.com/BFNOC/hideck/actions/runs/37796483023
  • 15 个任务全部成功，用时 20 分钟。Release 有 25 个文件，没有 warning
  • 9 次 SDK 获取：build-openwrt 的 3 次都命中缓存；打包的 6 次里，4 次第一次就下完（其中 3 次因为主站测速只有 70～130 KiB/s，直接用了另外两个下载源），2 次主站测速很快、之后变慢，到 240 秒上限（curl exit 28 from downloads.openwrt.org after 240s）后换下载源续传完成
  • Docker 发布被触发；因为不是 v 标签，按原有逻辑在解析标签时退出，没有走到推镜像
• 修改前的一轮完整测试（414f8f7）：https://github.com/BFNOC/hideck/actions/runs/37784458324 ，同样全部成功，9 次 SDK 获取里有 3 次主站到 240 秒上限后续传完成
• OpenWrt 失败的情况：https://github.com/BFNOC/hideck/actions/runs/37780289487/attempts/1
  • 临时加了一个只用于测试的提交，强制 OpenWrt arm64 失败（不在本 PR 中）
  • run 结论为 success，Release 照常发布，warning 为 Release published without openwrt_arm64 openwrt-packages (2/6); re-run the failed OpenWrt jobs to add them（之后改为 re-run the failed jobs to add them），Docker 发布被触发
  • 这一轮里主站出现了 exit 18（下到 84934656 字节断开）和 exit 28，都换下载源续传完成
  • 在这一轮上点了 Re-run failed jobs：失败的 arm64、全部 6 个打包任务和 release 都排入了重跑，我在 release 执行前取消了，没看到它重新发布
  • 这一轮跑的是审查修改前的版本。之后改了：零个打包时 warning 步骤不再报错、连续两次没进展才重下、单次 240 秒上限和尝试次数、测速失败的下载源不参与、只允许 HTTPS、上传加 overwrite: true、去掉一直超时的 mirror-03。这些在本地模拟过；完整一轮跑的是修改后的版本，但失败和重跑的情况没有再跑一次
  • 这一轮的版本号 ci-sdk-test 不是数字，25.12.5 的 APK 打包失败；dev 会被转成 0.0.0，完整一轮正常
• python3 -B -m unittest discover -s packaging/tests：全部通过。原来的测试要求下载命令带 --max-time 600，已改为检查新的下载方式，并新增脚本行为的测试

已知限制

• 缓存只覆盖 build-openwrt 的 3 个 SDK，按 ref 隔离：新标签用不上旧标签的缓存。默认分支上的缓存标签可以用，在 main 上手动跑一次 workflow_dispatch 可以预热（7 天没用到会被清掉）。主要还是靠续传和换下载源
• 没有在 v 标签上验证 OpenWrt 失败时的 Docker 推送，只验证到 run 结论为 success 和 Docker 发布被触发
• OpenWrt 任务跑满 30 分钟被取消的情况没有实测；脚本的尝试次数让它在超时前先失败
• warning 里打包数量 6 是写死的，对应当前的 sdk-matrix.json，release 任务没有 checkout，读不到这个文件
• ftp.halifax.rwth-aachen.de 是第三方镜像，靠固定的 sha256 保证内容正确

基于当前 main（8299cf5，即 v2.1.27），2 个提交，改 5 个文件。

[BFNOC]

modem-voice-ci 里 compile (windows, amd64) 的失败和本 PR 无关。在 main（8299cf5）上执行 GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build ./internal/modemvoice/... ./pkg/g711 也会报同样的 syscall.SO_REUSEPORT / syscall.Handle 错误，从 v2.1.24 加入 internal/modemvoice 起就是这样；本 PR 改到的 packaging/** 命中了这个 workflow 的路径过滤。其余 4 个 compile 是默认 fail-fast 连带取消的，本地都能通过；tests 和 runtime-image 都通过了。

原因是 internal/modemvoice/host 用到 voicehost 的类型，经 voice → imscore → ipsec3gpp → engine/ipsec 和 voice → voice/media 带进了 Windows 上编译不了的 socket 代码。Release 不包含 Windows，最简单是从 compile 矩阵里去掉 windows。

[BFNOC]

main 上的 cfe3866 已经修复了 SDK 下载问题，关闭本 PR。