# v6.3.15 AI回复：逐通知原帖绑定修复

## 现场问题
上一版已经可以成功发送回复，但不同成员的AI回复全部出现在同一个帖子下面。

这说明回复API已经能工作，真正问题是：
`get-notices` 的一页返回包含多条互动通知，而旧解析器允许“页级包装对象”进入通知解析。
随后递归查找 feed_id 时，会取到页面中的第一个 feed_id，并被多条通知复用。

## 本版修复

### 1. 一条通知就是一个独立解析单元
新增 `_notice_record_candidates`：
- 优先要求 notice_id/msg_id 是当前对象的直接字段。
- 一个候选对象如果包含多个不同 notice_id，会被认定为“页/列表包装对象”并排除。
- 兼容CLI不同结构时，只选择包含唯一 notice_id 的最小容器。
- 不再从整个 get-notices 返回页递归提取 feed_id。

### 2. 每条通知保存自己的 feed_id 候选
优先级：
1. 通知对象直接 feed_id
2. 包含 reply_id 的对象中的 feed_id
3. 包含 comment_id 的对象中的 feed_id
4. 当前通知内部其他 feed_id

候选不会跨到兄弟通知。

### 3. 多 feed_id 必须验证绑定
如果一条通知内部确实存在多个 feed_id：
- 对每个 feed_id + create_time 候选调用只读 get-feed-comments。
- comment_id/reply_id 能精确命中时立即确认。
- ID缺失时按互动正文 + 作者匹配。
- 只有“这条互动确实存在于该帖子评论中”才设置 feed_binding_verified=1。

不能验证时不会随便选择第一个有效帖子。

### 4. 原帖兜底增加安全门
以前 do-comment 兜底只要求 feed_id + feed_create_time 有效。
但“有效帖子”不等于“当前互动的帖子”。

现在：
- 单一 feed_id 的独立通知：可以正常兜底。
- 多 feed_id 通知：必须 feed_binding_verified=1 才允许 do-comment。
- 如果仍存在歧义，宁可本条报错，也绝不会回复到别人的帖子。

### 5. get-notices 正确分页
官方 feed 文档规定：
`get-notices` 的 stdin 分页字段是 `attach_info`。

本版按 notice type 4/5/6 分别分页：
- 每页50条
- attach_info 原样续传
- 最多20页安全上限
- 每一页单独拆分通知记录

### 6. 失败记录
只重置历史 status=failed 的记录。
已经成功发送、已经原帖兜底成功的记录不会重新发送，避免重复回复。

## 热更新
- VERSION 继续 v6.3.15。
- app/updater.py / make_update_package.py / bootstrap.py /
  licensing / license_public_key / 构建脚本保持指定 v6.3.12 原文件字节级不变。
