test(accept): 发布包级端到端验收（读 zip 内 APK）+ T-AND-014

`build/verify.sh` 验的是 app/build/outputs/ 里**刚构建**的 APK，而用户装的是 zip
里的 app-release.apk。两端都因此翻过车（Web v0.7.4 实体注册、Windows v0.2.1 的
PE 版本元数据），故三端统一：每次发布都要有一条读产物本身的验收（文档 §7.5）。

新增 build/accept-release.sh，对一个 zip（或已解压目录）跑完：
  1) sha256（有 SHA256SUMS 时）；
  2) 解压 + 文件清单（apk / README.txt / THIRD_PARTY.md / contracts/VERSION）；
  3) APK 的 AndroidManifest versionName/versionCode = 发布版本（复用
     check-apk-version.sh —— 安装界面与应用信息页读的就是它）；
  4) ABI 恰为 arm64-v8a + armeabi-v7a、无模拟器 ABI，且两个 ABI 下都有
     MediaPipe native 库（T-AND-012 崩溃根因之一）；
  5) assets/pose_landmarker_lite.task 在包内；dex 里仍有
     poselandmarker/PoseLandmarker（R8 没整体裁掉）；
  6) 有 apksigner 时顺带验签；
  7) 包内 contracts/VERSION 与仓库逐项一致（抓「APK 用旧契约构建、快照拷了新的」）。
package-release.sh 结尾打印下一步验收命令；README 补用法。

实测（对**已发布**的 v0.2.0 资产重新下载后跑）：sha256 OK、版本元数据 0.2.0/200、
ABI 恰为两个真机 ABI、两个 ABI 下都有 MediaPipe native、模型资源在、dex 命中
PoseLandmarker、apksigner 通过、契约快照与仓库一致 → 发布包级验收全部通过。

反向验证（真实负例）：
  * 篡改包内 contracts/VERSION 的 data-models=0.6.0 →
    ✗ data-models：包内 0.6.0，仓库 0.7.0，退出码 1；
  * 期望版本写 0.2.1 对 v0.2.0 的包 → ✗ versionName 是 '0.2.0'，期望 '0.2.1'
    且 ✗ versionCode 是 200，期望 201。

诚实声明：**装到真机跑 30 分钟**这条脚本替代不了，仍属设备实测项；本脚本能证明的是
「装得上、不会因打包配置而崩」。verify.sh 仍全绿。

README.txt

@@ -138,6 +138,12 @@ WebSocket 推送给 Windows 客户端，由后者驱动 VRM 角色并实时评
    $ANDROID_HOME/build-tools/34.0.0/apksigner verify app/build/outputs/apk/release/app-release.apk
      预期：退出码 0（无输出即通过）
 
+   0) 发布包级验收（对**发布包**而不是本地构建；文档 §7.5）
+      bash build/accept-release.sh dist-release/opendance-android-v0.2.0.zip
+      预期末行「发布包级验收全部通过」。它会校验 sha256、解压、核对文件清单、
+      读包内 APK 的 AndroidManifest 版本元数据、核对 ABI 与 MediaPipe native 库、
+      模型资源、dex 里的 PoseLandmarker、验签，以及包内契约快照与仓库是否一致。
+
    bash build/check-apk-version.sh app/build/outputs/apk/release/app-release.apk
      预期：AndroidManifest versionName = <project.yaml 的 version>
            AndroidManifest versionCode = 10000*主 + 100*次 + 修订