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.md

@@ -710,6 +710,22 @@ Next instruments, in order: whether the firmware waits for a key release before
 wait loop at 0x08013260 both before and after MENU), and whether the copy of an upstream app is ever entered when
 it is launched from the radio's own menu path rather than through this page.
 
+**Correction, same day: those PC measurements were taken on instances that never drew a screen, and the
+page's current firmware has no F+7 app menu at all.**
+
+Two things were wrong with the method above. First, every QEMU instance started by hand for these runs came up
+with a blank panel (0 lit pixels) while the page's own instance draws (803) -- the same image, 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**, not a finding. Second, driving the page's own /api/key and reading its /api/panel shows
+what the user sees: F, 7, DOWN x3 and MENU all answer ok and the screen does not change by a single pixel
+(ink 232 before and after every press). The page's firmware.bin is 109.3 KiB; the Labs build that does open the
+app menu is 111.9 KiB, i.e. a different build. The radio still answers 0x0730 with four committed apps, so it
+does support the app region -- it just has no F+7 entry, which is the Labs/UVStudio path.
+
+So the user-visible symptom ("cannot get into the program") is the key press doing nothing on this build, and
+the only way to test an overlay app is to run the Labs build itself. Measure through the page, not through a
+hand-started QEMU: it is the instance that draws, and its endpoints are the same ones the browser uses.
+
 ## The keypad: two real bugs, both fixed
 
 The old note here said "keys reach the firmware but the UI does not react" and

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，都已修复
 
 这里原来的笔记写的是"按键到达了固件但界面不反应"，并且归咎于机器模型。结果发现有**两个