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

@@ -886,6 +886,26 @@ the last mile.
 Next: the same variant harness on the three pieces of draw() separately (the header text, the 81-cell loop, the
 cursor), each with the loop spin that the surviving apps have.
 
+**Round 16: draw()'s halves are each fine, and the app is running -- so the next suspect is the blit itself.**
+
+Using the validated shape (for(;;) { long spin; one piece; }) the header block (display_clear + four print_tiny
+calls, the long strings and x=122 included) scores 26.1% and the 81-cell loop plus the cursor, written with local
+variables only, also scores 26.1% -- both the same as the control, so both are alive.
+
+The full Minesweeper, measured the same way, is running: 116 samples inside it over fifteen seconds, spread over
+eight distinct addresses (its spin at 0x200002e8/0x200002ec, plus 0x2000035a, 0x20000400, 0x20000564, 0x20000488
+and others), with the firmware still serving it -- 1024 font-region reads appear during the launch. Yet the panel
+never leaves the launcher's title box over ninety seconds, and that box is drawn before the app is entered, so
+nothing the app paints has ever reached the glass. Removing the opening settle spin changed nothing, which also
+retires the earlier idea that the app was simply still inside that spin.
+
+So the app runs, calls into the firmware, and never completes a frame. That leaves two candidates and one of them
+has never been checked: the statics (draw() reads g_cursor, g_state, g_mine_left, g_open, g_flag and g_mine, the
+only inputs the two surviving variants did not touch), 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 what its screen showed.
+The second is cheap to settle: an app that does nothing but display_clear plus blit_full should visibly erase the
+launcher's title box.
+
 That is where the next round starts: the same alternating-spin shape, one call at a time.
 trace. That is a much better place to be than the emulator mystery this started as.
 

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。比起一开始那个模拟器悬案，这是好得多的处境。