[JavaZeroo]

问题与最终行为

#194 要核对「resize 期间的 ConPTY 重绘与终端视口/缓冲是否对齐」，但现有 replay 只能按固定几何回放整段捕获：

usage: replay input rows columns history chunk

跨 DPI / 缩放 / 窗口恢复的捕获（144 → 192 → 96 → zoom75 → restored）无法忠实回放，这也是在 #194 里只能做单块回放、无法检验跨 resize 假设的原因。

本 PR 新增 resize_replay：读取同一份字节流，按外部步骤文件依次应用几何。

resize_replay input steps-file history

# steps-file 每行：<rows> <columns> <bytes> [label]
7   111  1650  geometry-main
7   111  1071  geometry-bottom

每一步：Screen::resize() → 消费对应字节 → 输出该步状态：

{"step":1,"label":"geometry-main","rows":7,"columns":111,"consumed":1650,
 "total_consumed":1650,"history":30,"retained":37,"top":30,"maximum_top":30,
 "following":true,"cursor_row":6,"cursor_column":0}

最后一行输出整份 screen JSON（与 replay 相同格式）。

验证

1. 与现有 replay 对拍：[R2][调查] 核对 resize 期间 ConPTY 重绘与终端视口/缓冲的对齐 #194 的 actions-geometry-main.transport.bin 在 7×111 下，
   两者都得到 retained=37 / history=30，新工具未改变回放语义。
2. 合成用例：3 行视口喂 12 行 → resize 到 5 行 → 再喂 8 行，得到
   history 10→16、retained 分别等于 history + 当前页高（13 / 21），视口始终 following。
3. 几何相关性回归（[R2][调查] 核对 resize 期间 ConPTY 重绘与终端视口/缓冲的对齐 #194 的实测结论）：同一份 20 行输入分别喂 4 / 10 / 24 行视口，
   断言 history 为 17 / 11 / 0，且 retained 始终等于 history + 页高。
   对应 [R2][调查] 核对 resize 期间 ConPTY 重绘与终端视口/缓冲的对齐 #194 在真实捕获上测到的「7 行页高推入 30 行历史、24 行页高推入 0 行」。
4. test_resize_replay.py 四条用例，注册为 CTest resize_replay_contract，本机通过：

1/1 Test #29: resize_replay_contract ... Passed 0.25 sec

性能影响（如适用）

不适用。新增离线诊断工具，运行期路径不调用；工具本身只做一次流式 feed。

来源与限制

• 动机、实测与机制实验见 #194 的三条证据评论
• 限制：本工具不产生缓存/重绘结论，只提供按时间线回放的观测手段；真正的根因仍需要分阶段的字节切片，而现有 artifact 只提供 geometry-main / geometry-bottom 两块，且进度日志没有字节偏移字段
• CMakeLists.txt 与 perf(r54): 把冻结成本批次与 hosted/CPU 诊断重放到 main（合并 #104–#107） #262、feat(core): 叠加式显示页坐标映射层（#29 的 view_mapping） #264 插入点相邻：本 PR 在 replay 之后加可执行目标、在 core 之后加 Python 测试注册；合并时若冲突只需保留全部插入