[JavaZeroo]

问题与最终行为

alacritty-headless (windows-2025) 反复在 candidate_shell_tui 失败。用 GitHub 的 job API 取每步结论（无需日志）定位到「Build and test candidate shell on Windows」，再用该 run 的 artifact 读到现场：

stage=50 bytes=1678 …
screen 第 23 行: "candidate-tui.txt" [New]
candidate-startup-log.txt: b'READY\n'
… unsupported terminal event kind

Vim 正常启动、[New] 与 READY 都已就位，场景却因为一个未处理的事件类型中止。

根因：事件分派不完整

unsupported terminal event kind 只在 experiments/shell/shell.cpp:826 抛出。对照 experiments/candidates/alacritty/src/ffi.rs:326-342，适配器会发出全部 13 种事件，而 shell 只处理 7 种：

kind	事件	修改前	修改后
1	PtyWrite	处理	处理
2 / 3	Title / ResetTitle	处理	处理
4	Bell	处理	处理
5 / 7 / 12	Wakeup / MouseCursorDirty / CursorBlinkingChange	处理	处理
6	Exit	处理	处理
8 / 9	ClipboardStore / ClipboardLoad	throw	忽略
10 / 11	ColorRequest / TextAreaSizeRequest	throw	忽略
13	ChildExit	throw	忽略

default: throw 保留——将来适配器新增 kind 仍会明确失败，而不是被静默吞掉。

忽略 8/9/10/11/13 的依据：该 harness 比较文字、模式与生命周期；它不拥有剪贴板，退出码从 session 读取，这些通知对它没有语义。

附带：缺少 Vim 时快速失败

candidate-tui 会在真实 shell 里键入 Vim 命令。缺少 Vim 时原先要跑满 33 秒场景超时才失败，唯一痕迹是 shell 回显的 not recognized。本 PR 在 run.py 的 execute() 入口加一次前置检查，缺失立即抛 RuntimeError 并指向 docs/research/joint-conpty-baseline.md。按 more-capture-ech.md「skip 不代替运行证据」，这里是失败而不是 skip。（原 #267 的 workflow PATH 步骤已被证伪并移除：本 PR 不含它时两个 Windows 作业仍以 5m50s / 6m05s 通过。）

验证

• CI：本 PR 的 alacritty-headless (windows-2025) 两个作业均通过（5m50s / 6m05s），这是修复前后的直接对照
• 覆盖完整性：修改后 case 分支覆盖 kind 1–13 全部取值，与 ffi.rs 映射一一对应
• 本地：装上与 CI 同源 Vim 9.1 后，合并树（11 个 PR）的候选配置下 candidate_core 1.66s、candidate_shell_tui 9.30s 通过；默认配置 67/67 通过
• 守卫：本机无 Vim 时在 0.17 秒抛出带文档指引的 RuntimeError；非 candidate-tui 模式不受影响

性能影响（如适用）

不适用。仅增加事件分支与一次 PATH 查找。

来源与限制

• 现场证据：CI artifact 的 sample.json（stderr 与 screen）与该轮 candidate-startup-log.txt
• 限制：本地无法复现 "unsupported terminal event kind" 的具体触发（同版本 Vim 在本机通过），因此事件部分是按「该串唯一抛出点 + 映射穷尽」定位的；CI 对照是主要验证
• 本 PR 不改变 candidate-tui 的任何断言