Round 16: draw()'s halves are each alive, so the blit is the next suspect

With the validated shape (for(;;) { long spin; one piece; }) the header block scores 26.1% and the 81-cell loop plus cursor, with locals only, also 26.1% -- both equal to the control, so both are alive. The full Minesweeper is running too: 116 samples inside it over fifteen seconds across eight distinct addresses, with the firmware still serving it (1024 font-region reads), yet the panel never leaves the launcher's title box over ninety seconds, and that box is painted before the app is entered. Removing the opening settle spin changed nothing, which retires the idea that it was still inside that spin.

Two candidates remain: the statics, which draw() reads and neither surviving variant touched, and whether blit_full from an overlay app reaches the panel model at all -- the gutted variant was only ever measured by its PC share, never by its screen.

AGENTS.zh-CN.md

@@ -724,6 +724,21 @@ print_tiny、帧缓冲写入与光标反相 —— 这就是最后一公里。
 
 下一步：用同一套变体装置分别测 draw() 的三块（标题文字、81 格循环、光标），每块都带上那些能活的应用所拥有的循环自旋。
 
+**第 16 轮：draw() 的两半各自都没问题，而应用确实在跑 —— 下一个嫌疑是 blit 本身。**
+
+用已验证的形状（for(;;) { 长自旋 ; 一块代码 }）测：标题区（display_clear + 四次 print_tiny，含长字符串与 x=122）
+得 26.1%；81 格循环加光标（只用局部变量写）也得 26.1% —— 都与对照组相同，即两者都活着。
+
+完整版扫雷用同样方式测，**它在跑**：十五秒里有 116 个样本落在它里面，分布在八个不同地址（自旋在 0x200002e8/
+0x200002ec，另有 0x2000035a、0x20000400、0x20000564、0x20000488 等），固件仍在为它服务 —— 启动期间出现 1024 次
+字体区读取。然而九十秒里面板始终没有离开启动器的标题框，而那个框是在应用被跳进去**之前**画的，所以应用画的东西
+从未到达玻璃。去掉开场自旋也没有任何变化，这同时否掉了先前那个「应用还卡在自旋里」的想法。
+
+结论：应用在跑、也在调用固件，却从未完成一帧。剩下两个候选，而其中一个**从未被检查过**：静态变量（draw() 会读
+g_cursor、g_state、g_mine_left、g_open、g_flag、g_mine —— 正是两个存活变体都没碰过的输入），以及
+**从叠加应用发出的 blit_full 到底有没有送到面板模型** —— 掏空版当初只量了 PC 占比，从没看它的屏幕显示了什么。
+第二个很便宜就能定论：一个只做 display_clear + blit_full 的应用，应当明显擦掉启动器的标题框。
+
 下一轮就从这里开始：同样的「自旋 + 单调用」形状，一次只放一个调用。
 进去、读同一份 trace。比起一开始那个模拟器悬案，这是好得多的处境。