Find the screen buffers in the firmware instead of hardcoding one build's

The page was told --frame-addr 0x200012BE --status-addr 0x2000163E and used them as a fallback. The firmware the user actually flashed keeps its buffers at 0x2000129E/0x2000161E, 32 bytes earlier, so every line landed 32 bytes off: that is the "other firmware looks shifted" report. The images here are minimal ELFs with no symbol table, so there is nothing to read -- but the firmware's own buffers hold the same bytes the controller holds, and tools/uvk5_buffers.py finds them by matching (1024/1024 bytes for that file).

The two address flags are optional now, work/run-webui.ps1 passes no machine-specific values at all, and the page reports what it found in /api/status and /api/panel. tools/uvk5_testenv.qemu() also looks in the sibling qemu-7.2/build the rest of the repo assumes. Fixed /api/panel's emulator-off branch, which called jsonify with both a dict and kwargs and 500'd.

Tests: test_uvk5_buffers (the search must count matches, not pairs -- its first version scored every offset full marks and always answered the first one).

AGENTS.zh-CN.md

@@ -400,6 +400,31 @@ PTT+SIDE1/SIDE2 与 MENU（那是应用的几个特殊模式）、开机窗口
 错答案**；而一个偏了四列的字节，在"重要的东西恰好住在那四列里"之前，是看不出来的。要报出来源，
 并且要测"该走的那条优选路径确实被走了"。
 
+### 屏幕缓冲是**找出来**的，不是写死的
+
+原来是个默认值：`--frame-addr 0x200012BE --status-addr 0x2000163E` —— 那是**某一份构建**的地址，
+被写进启动脚本当默认值。换成把缓冲放在别处的固件，画面就"貌似合理但错"：实测用户真正刷进去的那份，
+缓冲在 `0x2000129E` / `0x2000161E`，正好**早 32 字节**，于是**每一行都偏 32 字节**。这就是「换个
+固件就偏移」的本来面目。
+
+其实什么都不用假设。这里的固件镜像是**最小 ELF** —— 一个程序头、没有节头、没有符号表
+（`tools/bin2elf.py` 就是这么写的）—— 所以**没有** `gFrameBuffer` 符号可读；但它有**行为**：
+固件自己的缓冲里存着与控制器**相同的字节**，因为驱动就是从那拷贝过去的。
+`tools/uvk5_buffers.py` 把控制器显存沿着 SRAM 滑动，取吻合度最高的那个偏移；对用户刷的那份文件，
+它给出 1024/1024 字节吻合和**正确**的一对地址。
+
+于是 `--frame-addr` / `--status-addr` 现在都是可选的 ✓，`work/run-webui.ps1` 不再传它们
+（也不再有任何本机路径 ✓），页面会报出自己找到了什么：
+
+    buffers: {"frame": 0x2000129E, "status": 0x2000161E, "how": "sram search",
+              "score": 1024, "total": 1024}
+
+两条习惯，这份文件里用别的话说过：**默认值里写进"某台机器/某份构建"的具体值，就是在等第二份构建来踩**；
+以及 **没有符号可读时，就直接问它本人** —— 缓冲里的字节就是答案，靠**匹配**找出来，而不是猜。
+
+面板路径完全不需要这些，而页面画的正是它：对任何固件，控制器的显存就是屏幕。这些地址只服务
+guest RAM 回落路径 —— 所以搜索失败会被报出来，而不会挡住任何东西。
+
 ## 键盘：两个真 bug，都已修复
 
 这里原来的笔记写的是"按键到达了固件但界面不反应"，并且归咎于机器模型。结果发现有**两个