# v6.3.15 评论读取链路彻底修复

## 最新现场
新互动已经识别成功，但楼层定位失败，错误稳定为：
“评论列表读取为空”。

## 找到的代码级不一致
`_probe_feed_create_time()`：
- 优先通过 `get-feed-comments --feed-id ... --feed-create-time ...` flag模式验证。

`_load_feed_comments_for_interaction()`：
- 之前只走stdin JSON模式。

因此同一台机器可能出现：
1. flag模式验证帖子时间成功；
2. 真正加载评论时stdin schema/参数兼容问题；
3. 返回空/失败；
4. 程序误以为“帖子没有评论”。

## 新版评论读取
每一页按以下顺序尝试：
1. CLI flags：
   - --feed-id
   - --feed-create-time
   - --guild-id / --channel-id（CLI支持时）
   - --count
   - --attach-info
2. stdin最小参数：
   - feed_id
   - feed_create_time
   - count
   - attach_info
3. stdin完整参数：
   - guild_id
   - channel_id
   - feed_id
   - feed_create_time
   - count
   - attach_info

只要任一方式返回真实comment_id/reply_id，就采用该结果。

## feed_create_time恢复
如果当前feed_create_time返回0条评论：
- 自动读取通知中的其他原始时间候选；
- 对每个候选执行只读get-feed-comments；
- 找到真正返回评论的时间后：
  - 写回当前互动上下文；
  - 更新ai_feed_context_index；
  - 后续同帖子直接复用。

不会执行任何写操作来试探时间。

## 楼中楼
get-next-page-replies同步改成：
- flags优先
- stdin最小回退
- stdin完整回退

分页仍严格使用上一页返回的attach_info。

## 诊断
“评论列表为空”不再是一个模糊错误。

现在会区分：
- 评论接口调用成功但返回0条；
- flag/stdin三种方式全部失败；
- OIDB限流；
- 缺feed_id；
- 缺feed_create_time候选。

失败时ai_reply_diagnostics.log会保留各尝试的：
- 模式
- CLI退出码
- 是否success
- comment row数量
- 返回摘要

不记录Token或DeepSeek Key。

## 直接通知ref
如果type4/type5通知本身带精确notice_ref：
发送前直接允许官方：
`feed do-reply --ref ...`

因为官方CLI会自己解析通知对应评论。
此路径仍是do-reply，不是do-comment。

## 安全
AI自动发送器仍然没有do-comment路径。
评论读取失败时不会新增一级评论。

## 热更新
VERSION继续v6.3.15。
v6.3.12热更新核心文件保持字节级不变。
