[Bug] MuMu 已在线后任务无限挂起（无任何后续日志），阻塞后续队列且 MAS 无法退出 #1863

环境

• Windows 11 25H2（build 26200）
• AUTO-MAS v5.8.0-beta.3
• MuMu 12，实例 1
• MAA v6.8.0（本次任务为 MAA/明日方舟）
• 涉及队列「日常」，定时点为本地 04:00 与 17:00（配置中存 UTC：20:00Z / 09:00Z）

问题

定时队列 04:00 启动后，MuMu 实例已在线，然后没有任何后续日志，任务无限挂起 5 小时，直到 09:12 手动关闭 MAS 仍未结束；期间 MAS 主线程仍正常响应（整点 QQ 重连、例行配置查询都在跑）。

连带影响：

• 04:00 这一班的 7 个托管项全部没跑
• 该任务一直占着调度直到手动关闭 MAS，期间调度队列无法释放（本机该队列的另一个定时点是 17:00，尚未到触发时间，因此无法观测第二个定时点是否受影响）
• 关闭 MAS 时停在 等待全部任务中的子任务结束...，无法正常退出

时间线（app.log）

04:00:00.981  主业务定时器 | 定时唤起任务：54c01f8b-...
04:00:01.075  业务调度   | 开始运行任务，包含 7 个托管项
04:00:01.208  任务开始: fc151f95-...（MAA）
04:00:14.734  MuMu模拟器管理 | 开始启动模拟器 1
              ↑ 同一行上方：MuMuManager info -v 1 耗时 13.156 秒（正常约 0.1 秒，异常慢）
04:00:17.504  MuMu 启动命令已返回，等待实例在线: 1
04:00:29.453  MuMu模拟器管理 | 模拟器已在线: 1 - 用时 11.953 秒
              ↓ 之后 5 小时没有任何任务日志
09:12:52.735  业务调度 | 中止任务: ALL
09:12:52.736  业务调度 | 等待全部任务中的子任务结束...（此后无输出）

MAA 自身日志（E:\MAA\MAA-win-x64-v6.8.0\debug\asst.log）最后一条为 11-06 17:13，说明本次任务里 MAA 从未被拉起（正常流程应出现「启动MAA进程」）。

与 #1506 的区别

#1506 的现象是先打出 开始检查 MuMu 应用前台状态，然后在 300 秒预算内长时间等待。

本例中 04:00–04:40 的日志里**「前台」相关行数为 0**，也就是说根本没有进入前台探测阶段，挂起发生在「模拟器已在线」之后、前台检查之前。

可疑位置

repo/app/utils/common/emulator/mumu.py 第 387 行 _block_store_overlay_ads()：

result = await ProcessRunner.run_process(
    self.emulator_path, "adb", "-v", idx, "shell", "appops", "set", ...,
    timeout=10, if_merge_std=True, breakaway=True)

这一句在「已在线」之后、应用启动检查之前执行。正常情况下它会在约 2 秒内返回并打印一条警告（本机 appops 不存在）：

09:16:19  WARNING 屏蔽 MuMu 应用商店悬浮广告失败: /system/bin/sh: appops: inaccessible or not found

但 04:00 那次既没有「已屏蔽」，也没有「屏蔽失败」，且没有任何 子进程已退出 记录 —— 说明这个 await 从未返回。

timeout=10 看起来存在但没有生效，怀疑是典型子进程管道问题：超时只终止了直接子进程，而 adb 后台服务继承了合并后的 stdout 管道，读取端等不到 EOF，协程永久阻塞。

对照：同一天 09:16 同一流程正常

09:16:05  开始启动模拟器 1
09:16:17  模拟器已在线: 1 - 用时 8.516 秒
09:16:19  屏蔽 MuMu 应用商店悬浮广告失败: appops: inaccessible or not found
09:16:23  开始启动模拟器 1 - com.hypergryph.arknights
09:16:24  启动MAA进程

差异：卡死那次的 info -v 1 花了 13 秒（正常 0.1 秒），说明当时 MuMu/adb 状态异常，正好撞上该调用。

建议

1. 前置阶段（拉起 MAA 之前）也需要任务级超时：现在 MAA 的 HardTimeLimit 只覆盖 MAA 启动后的阶段，因此挂在这里可以无限期
2. run_process 超时时应终止整个进程树并强制关闭管道，而不是只杀直接子进程
3. 或给 _block_store_overlay_ads 这类"纯优化"步骤加 asyncio.wait_for 外壳，超时直接放弃该步骤继续主流程

另：Function.IfBlockAd 关闭后即可跳过这条调用，可作为用户的临时规避手段。

需要完整日志我可以提供（MAS 本体日志、MAA 日志、MuMu shell 日志）。