Correct the overlay measurements: they were taken on blank instances, and this build has no F+7 menu

Hand-started QEMU instances all came up with a blank panel (0 lit pixels) while the page's own instance draws (803), same image and a different firmware file, so 'the PC never entered the overlay' was measured on a radio that never reached its main loop and is inconclusive rather than a finding.

Driving the page's own /api/key and reading /api/panel reproduces what the user sees: F, 7, DOWN x3 and MENU all answer ok and the screen does not change by a pixel (ink 232 throughout). The page's firmware.bin is 109.3 KiB and the Labs build that does open the app menu is 111.9 KiB -- a different build. The radio still answers 0x0730 with four committed apps, so it supports the app region but has no F+7 entry. Testing an overlay app requires running the Labs build, and measuring through the page rather than a hand-started QEMU.

AGENTS.zh-CN.md

@@ -576,6 +576,18 @@ app 区被读过 —— 而多系统菜单读的是**固件槽**，不是应用
 接下来该用的仪器，按顺序：固件在跳转前是否在等按键释放（按 MENU 前后 PC 都停在 0x08013260 这个等待循环里）；
 以及从**电台自己的菜单路径**启动上游应用时，拷贝进去的代码到底有没有被执行。
 
+**同日更正：上面那些 PC 测量是在"从来没画出画面"的实例上做的；而且页面当前那份固件根本没有 F+7 应用菜单。**
+
+方法上有两处错误。第一，这些运行里由我手工启动的每一个 QEMU 实例，面板都是空的（点亮像素 0），而页面自己的
+实例是画的（803）—— 同一份镜像、**不同的固件文件**。所以"PC 从未进入叠加区"是在一块**从未跑到主循环**的
+电台上的测量，属于**不成立**，不是结论。第二，直接驱动页面自己的 /api/key 并读它的 /api/panel，得到的就是
+用户看到的现象：F、7、DOWN×3、MENU 全部返回 ok，而画面**一个像素都没变**（每次按键前后 ink 都是 232）。
+页面的 firmware.bin 是 109.3 KiB；而能打开应用菜单的 Labs 版是 111.9 KiB，**不是同一份构建**。电台仍然能回答
+0x0730 并列出四个已提交应用，说明它**支持应用区**，只是**没有 F+7 这个入口**（那是 Labs/UVStudio 的路径）。
+
+所以用户看到的"进不去程序"，实质是**这份构建上按键不生效**；要测叠加应用，只能**跑 Labs 版本身**。
+测量要走**页面**，不要走手工启动的 QEMU：会画的是页面那个实例，而它的接口就是浏览器在用的同一套。
+
 ## 键盘：两个真 bug，都已修复
 
 这里原来的笔记写的是"按键到达了固件但界面不反应"，并且归咎于机器模型。结果发现有**两个