feat(adapter): 新增 Reasonix CLI 适配器

[Hezi-crypto]

新增 Reasonix CLI 的注册、配置、会话捕获与精确恢复支持。通过 lease PID、进程树及会话元数据关联原生 session id，避免同目录并发会话串线。

终端行为与已知限制：

• Reasonix 1.19.3 启动后主动进入 alternate screen，暂不支持 --no-alt-screen。
• 实测 tmux 状态为 alternate_on=1、history_size=0；对话历史由 Bubble Tea viewport 管理。
• Claude Code 与 Codex 使用普通屏幕及 tmux scrollback，现有截图翻页基于 tmux copy-mode，适用于二者。
• Reasonix 的截图翻页无法读取应用内历史；将 adapter 的 altScreen 改为 false 也不会改变 Reasonix 的终端行为。

验证：

• pnpm build
• pnpm exec vitest run test/reasonix-adapter.test.ts test/cli-adapters.test.ts（334 tests passed）
• git diff --check

[deepcoldy]

复审进度（Codex）：

• 已确认复审基线固定为 0d1e06f2e088fa033357cd882ce2c10840c28293，与 PR 当前 head 一致；工作树干净。
• 本轮不重复首审已完成的 build / 496 tests，重点交叉验证：捕获失败后是否重试、首轮 capture 对输入队列的阻塞、PID namespace 进程树归属、仅有 comm 映射时的 discovery/adopt 行为、Reasonix 1.19.3 外部契约。
• 未经申晗确认不会合并。

[deepcoldy]

复审结论：🔴 请求修改（1 个 P1）

P1：捕获到的 Reasonix machine id 无法用于 --resume

内联：#729 (comment)

当前“精确恢复”主链存在两层确定性问题：

1. Reasonix v1.19.3 的 session list 返回 session_<HMAC> machine id；交互启动的 --resume 只解析 transcript 路径、raw branch stem/base 或文本查询，不识别 machine id。因此即使捕获成功，重启生成的 reasonix --resume session_... 也无法命中会话。
2. 捕获约 1 秒后即永久 disarm；但 Reasonix 首次 Enter 后只先写 in-flight meta，正文通常到 turn 完成或 30 秒 autosave 才持久化，session list 又过滤未持久化 turn。正常首轮通常抓不到 id，之后也不会再尝试。

建议从 lease 已定位出的 transcript stem/path 中保存 Reasonix 真正接受的恢复标识，并把捕获从 writeInput 的同步等待链拆开，允许失败后重试；单纯扩大 session list 重试窗口既不能修复 id 类型，也会放大输入队列阻塞。

其余重点复核

• writeInput 内联 capture 确实会占住 flushPending；理论上最坏 3×8s + delay。它与 P1 属于同一捕获设计，应在同一修复中消除，未重复列第二个阻断。
• Linux PID namespace 的方向正确：lease 的 namespace-local PID 可由 host /proc/<host-pid>/status 的 NSpid 映射；children BFS 从 botmux 持有的 host root PID 向下走。256 节点对单 CLI 树合理，macOS 仍走 ps 父链。
• reasonix / reasonix.js comm 映射只让 live pane 可被 discovery 发现；Reasonix 不在 structured bridge/adopt-input allowlist，所以不会生成半残 bridge，行为与 kiro-cli 一类，落普通 quiescence adopt。
• 用官方 v1.19.3 发布二进制与对应 tag 源码抽验：--yolo、两个 provider/model ref、隐藏的 session list --json --project-root、.jsonl.lease.json/.jsonl.meta 字段和默认 project layout 均成立。

官方契约对照：

• Reasonix v1.19.3 session machine interface
• Reasonix v1.19.3 resume query resolver
• Reasonix v1.19.3 turn persistence timing

本轮实际验证

官方 release: reasonix v1.19.3
pnpm exec vitest run test/reasonix-adapter.test.ts test/cli-adapters.test.ts test/fs-policy.test.ts test/worker-pipe-initial-screen-order.test.ts
→ 4 files passed, 426 tests passed
git diff --check <base>...HEAD
→ clean

影响面：P1 位于 Reasonix adapter 的公共 writeInput → persistCliSessionId → restart/resume 链，影响 Reasonix 的 PTY/tmux/zellij 等所有 botmux 自管 spawn；其它 CLI adapter 未改。worker 的 immediate/late PID wiring 和普通 adopt 路径未发现跨 CLI 回归。

未经申晗确认不合并。

[deepcoldy]

复审结论：✅ P1 已由 0e55f4017 完整修复，解除此前的 REQUEST_CHANGES。 本轮未发现新的阻断问题。

我重点重新验证了此前依赖外部契约的两条前提，而不是只看单测：

1. lease 在首轮输入前已可用。 用官方 @reasonix/cli-linux-x64@1.19.3、隔离的 REASONIX_HOME 实际启动 TUI；尚未提交任何 prompt 时，目标 project 的 sessions 目录已经出现 <stem>.jsonl.lease.json，其中 PID 与运行进程一致，此时 <stem>.jsonl 尚不存在。该行为也与 v1.19.3 源码链一致：fresh path 生成后，CLI 在 newChatTUI 之前执行 leases.Rebind(ctrl.SessionPath())，TryAcquireSessionLease 随即原子写 lease info。
2. 交互式 --resume <stem> 确实恢复。 在同一隔离环境提交一轮使 transcript 落盘，退出后执行 reasonix --yolo --resume 20260805-094817.044093996-deepseek-v4-flash；TUI 正常进入并重放上一轮 hello，没有走 session show 子命令，也没有 no session matches。源码中的 resolveSessionQuery 同样会将 stem 与 BranchID / basename 精确匹配。

对 delta 的代码核对：

• 删除 session list --json / machine id 捕获及其阻塞式子进程重试，改为从本 CLI 进程树拥有的 lease 直接取 stem；
• capturePending 只在成功捕获后关闭，早期 miss 会在后续 submit 重试；
• writeInput 不再承受最坏约 25 秒的 inline capture；
• 新增 checkResumeTargetExists，以 <stem>.jsonl 是否存在决定是否精确恢复，坏目标直接降级 fresh；
• 修复 commit 仅改 src/adapters/cli/reasonix.ts 与对应测试，没有触碰共享 adapter/worker 路径。

本轮实际验证：

• pnpm build：通过；
• pnpm exec vitest run test/reasonix-adapter.test.ts test/cli-adapters.test.ts test/fs-policy.test.ts test/worker-pipe-initial-screen-order.test.ts：4 files / 430 tests 全绿；
• git diff --check：通过；
• 复审时远端 head 与本地一致：0e55f4017c3e9ec39df4a9d8bf1d0de63a019c1c。

影响面评估：功能改动仍局限于 Reasonix adapter；Pty/Tmux 共用输入测试、共享 CLI adapter 注册/参数测试及 fs policy 均通过。未做合并，等待申晗确认。