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 仍全绿。

project.yaml

@@ -78,6 +78,10 @@ tasks:
     file: tasks/013-apk-version.md
     scope: APK 产物版本元数据（AndroidManifest 的 versionName/versionCode）校验 + 打包脚本 die 未定义修复
     status: done
+  - id: T-AND-014
+    file: tasks/014-release-acceptance.md
+    scope: 发布包级端到端验收（读 zip 内 APK：版本元数据 / ABI+MediaPipe native / 模型资源 / R8 / 契约快照）
+    status: done
 
 deliverable:
   artifact: opendance-android-v0.2.0.apk