Correct the overlay cause: the log order rules the sector-cache overwrite out

The flash probe records every transaction in order and the last one for that launch is the app's own code load (addr=103000 len=544, first bytes f0b583b0); nothing follows before the app is gone, so no font or resource read lands on the running app in that window. The 7848 font-region reads in the log belong to the firmware's own repainting.

What stands measured: the loader copies and jumps (a PC sample lands in the overlay, and a 16-byte app that calls nothing loops there forever); the app dies well under 100 ms (panel reads at t+113 ms still show the menu, at t+193 ms only the launcher's title box); an app that spins first survives a bar, a blit and led and dies around delay_ms; one that calls blit immediately is gone before it can be seen. Next: drop the PC probe interval from 100 ms to a couple of milliseconds, which is a one-line model change and turns it into a real trace of the app's short life.

AGENTS.md

@@ -771,6 +771,25 @@ must gate the sector cache while an app is loaded, and **that gate is what the m
 Next: find the gate in the firmware's flash driver (a memory flag, a register, a GPIO) and check what the model
 answers for it. This is the first time the failure has a name and a reproducible three-app comparison behind it.
 
+**Correction: the sector-cache explanation is not supported by the log order.**
+
+The flash probe records every transaction in order, and the last one for that launch is the app's own
+code load (addr=103000 len=544, first bytes f0b583b0). Nothing follows it before the app is gone, so no
+font or resource read lands on top of the running app in that window -- the sector-cache overwrite cannot
+be the cause here. What the log does show is 7848 reads in the font region over the session, all of them
+part of the firmware's own repainting rather than the app's life.
+
+Where that leaves the search, with everything that is actually measured: the loader copies and jumps (a
+sample lands inside the overlay, and the 16-byte app that calls nothing loops there forever); the app then
+dies within well under 100 ms (panel reads at t+113 ms still show the menu and at t+193 ms the launcher's
+title box alone); an app that spins first survives a bar plus blit plus led and dies around delay_ms; and
+one that calls blit immediately is gone before anything of it can be seen. The killer is inside the first
+hundred milliseconds and is not a flash read.
+
+Next instrument, and it needs a one-line model change rather than more guessing: the PC probe ticks every
+100 ms, which is the same order as the app's whole life. Dropping that interval to a couple of milliseconds
+turns it into a real trace and would show where in the overlay the app stops.
+
 ## 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

@@ -627,6 +627,21 @@ app 区被读过 —— 而多系统菜单读的是**固件槽**，不是应用
 下一步：在固件的 flash 驱动里找到这道门（一个内存标志、一个寄存器、还是一根 GPIO），再看模型在被问到时答的是什么。
 这是第一次，这个故障有了名字、也有了三个应用的可复现对照。
 
+**更正：扇区缓存这条解释，与日志的时间顺序不符。**
+
+flash 探针是按顺序记录每一笔事务的，而那一次启动的**最后一笔**正是应用自己的代码加载
+（addr=103000 len=544，首字节 f0b583b0）。此后到应用消失为止**没有任何事务** —— 也就是说，在那个窗口里
+**没有**字库或资源读取压在运行中的应用头上，**扇区缓存被覆盖在这里不可能是原因**。日志真正显示的是：整个会话里
+有 7848 次字体区读取，它们都属于固件自己重绘画面的过程，而不属于应用的生命期。
+
+于是搜索范围收敛到（只列实测过的）：加载器会拷贝并跳转（有采样落在叠加区内，而且那个 16 字节、什么都不
+调用的应用能在里面永远循环）；应用随后在**远不到 100 ms** 内死亡（t+113 ms 读屏还是菜单，t+193 ms 只剩启动器
+的标题框）；先自旋再动作的应用能活过一条横杠 + blit + led，而在 delay_ms 附近死掉；一上来就调 blit 的应用
+则连影子都还没留下就没了。**凶手在这最初的一百毫秒之内，而且不是 flash 读取。**
+
+下一个仪器，只需要改模型一行而不是继续猜：PC 探针每 100 ms 采样一次，而应用整个生命期就是这个量级。把这个
+间隔降到几毫秒，它就变成真正的 trace，能看出应用**停在叠加区的哪个位置**。
+
 ## 键盘：两个真 bug，都已修复
 
 这里原来的笔记写的是"按键到达了固件但界面不反应"，并且归咎于机器模型。结果发现有**两个